Medical fluid delivery systems including mobile platforms for patient engagement and treatment compliance

Abstract

To provide a patient platform for patient engagement and treatment compliance.SOLUTION: In an example, a processor is configured to obtain medical information from a patient for engagement and treatment compliance tracking. To obtain the medical information, the processor causes a user interface to be displayed with fields to be populated with medical information. After receiving a selection of a data field, the processor provides an option to enter medical information from an image. If the option is selected, the processor receives a recorded image of a medical device or a screen of a medical device, extracts text from the image, enables a selection of at least a portion of the text from the image, and writes the selected text from the image into the data field of the user interface as the medical information. The processor transmits the medical information to a patient medical record stored in a clinician database.SELECTED DRAWING: Figure 1

Description

Background Art

[0001] Engaging with patients outside of a medical environment over a long period of time is currently a virtually impossible task. Similar to becoming a gym member or purchasing a treadmill, many patients are typically prone to being overly enthusiastic. For example, from the start, patients are likely to readily adopt self-administered medical treatments (e.g., medical fluid delivery treatments) in their homes. With regard to treatment, patients need to connect themselves to a medical fluid delivery machine (or a container containing renal failure treatment fluid) to clean their blood from the accumulation of toxins. Part of the treatment may include tasks that patients need to perform, such as weighing themselves, measuring their blood, and / or recording information related to their treatment. Information recorded by patients is often scrutinized by clinicians to ensure that the treatment is progressing as prescribed. Clinicians also scrutinize the recorded data to determine whether adjustment of the treatment is required.

[0002] Over time, many patients become less motivated to undergo treatment as the treatment loses its novelty and becomes a routine obligation. As can be imagined, patients would rather engage in more exciting, relaxing, or stimulating activities compared to self-administered medical treatments. While patients are undergoing treatment, they sometimes begin to omit performing the additional tasks associated with the treatment. Omitting the additional tasks and becoming less motivated to undergo treatment has the potential to create a gap in the clinical supervision of the ongoing treatment. As patients become less involved in the treatment, they may begin to skip it or complete it without doing it properly, putting their health at risk in the process.

Summary of the Invention

Means for Solving the Problems

[0003] A medical fluid data transfer system, including a mobile platform, is disclosed herein. The medical fluid data transfer system is configured to improve patient engagement and / or treatment compliance through interactions provided through the patient's portable device (e.g., a cellular phone, smartphone, tablet computer, etc.). Specifically, the medical fluid data transfer system provides the patient with enhanced feedback and control (without feeling overwhelmed), making the patient feel that they are in control of their own treatment rather than simply following orders from a clinician. For example, a personal mobile communication device in the medical fluid data transfer system may display treatment information and / or patient vital sign data. The personal mobile communication device may also allow the patient to switch between different prescribed treatments or programs without the need to directly program the medical fluid delivery machine. Patients who feel in control are more likely to remain engaged in their own treatment.

[0004] Exemplary medical fluid data transfer systems also reduce the data aggregation burden on patients by automating processes. For example, a personal mobile communication device allows patients to capture treatment data or vital sign data for automatic transmission to a centralized clinician database. Patients may input data directly into their personal mobile communication device, receive data electronically from connected machines, or record data using a camera. The data is then transmitted within the medical fluid data transfer system to a database that stores the data in the patient's medical records.

[0005] In addition, the exemplary medical fluid data transfer system provides clinicians with a gateway to enable patients to communicate with clinicians in real time regarding any concerns or questions about medical fluid delivery therapy. In some embodiments, the medical fluid data transfer system also provides patients with access to educational or training materials. Thus, the exemplary medical fluid data transfer system is configured to connect patients to the assistance required or requested to remain engaged in and / or adhere to their treatment.

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

[0007] The modalities described above may be provided by a medical fluid delivery machine that houses components necessary for delivering medical fluids, such as one or more pumps, valves, heaters, direct-connected medical fluid generators, sensors such as one, two or more, or all of the following: a user interface, and a control unit that may employ one or more processors and memory for controlling the devices described above. The medical fluid delivery machine may also include one or more filters, such as dialyzers or hemofilters for cleaning blood and / or ultrafilters for purifying water, dialysate, or other fluids.

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

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

[0010] In light of the disclosure herein and without limiting this disclosure in any way, unless otherwise specified, in a first aspect of this disclosure that can be combined with any other aspects enumerated herein, the machine-accessible device, when executed, has instructions that cause the machine to input data into the patient medical records of a clinical system by operating a camera and recording images, operating a display interface and 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 and acquiring medical information. The processor is operated to acquire medical information by displaying a user interface via the display interface with fields into which medical information should be entered, and, after the selection of data fields in the user interface, graphically providing via the display interface a first option for inputting medical information from images and a second option for inputting medical information via text input. If the first option is selected, the processor receives an image recorded from a camera, the recorded image including a medical device or the screen of a medical device, extracts text from the image, allows selection of at least a portion of the text from the image via the display interface, and writes the selected text from the image as medical information to a data field in the user interface. If the second option is selected, the processor allows text input to the data field as medical information via the display interface. The processor can also be operated to retrieve medical information by transmitting the medical information written to the data field to the patient medical record stored in the clinician database after the transmit command is received.

[0011] According to a second aspect of the present disclosure, which may be used in combination with any other aspects enumerated herein unless otherwise noted, a machine-accessible device further comprises instructions stored thereon that, when executed, cause a processor to operate to determine a data template for extracted text on an image, to process the extracted text using the data template, to categorize the extracted text into fields, to enable selection of at least one of the fields, and to write the selected text from the image to a data field in a user interface.

[0012] According to a third aspect of this disclosure, which may be used in combination with any other aspects enumerated herein unless otherwise noted, the data template is configured to define the context of the text extracted in relation to the text location within the image.

[0013] According to a fourth aspect of the present disclosure, which may be used in combination with any other aspects enumerated herein unless otherwise noted, a machine-accessible device further comprises instructions stored thereon, which, when executed, cause a machine to operate a processor to determine a data template based on (i) a selection of a medical device type via a user interface, (ii) information scanned from an identifier located on the medical device, and (iii) at least one of signs in extracted text, or (iv) the relative arrangement of extracted text.

[0014] Unless otherwise noted, according to the fifth aspect of this disclosure, which may be used in combination with any other aspects enumerated herein, an identifier located on a medical device includes at least one of a quick response ("QR") code, barcode, serial number, or hardware number located on the housing of the medical device or on the screen of the medical device.

[0015] Unless otherwise noted, according to the sixth aspect of this disclosure, which may be used in combination with any other aspects listed herein, a medical device includes at least a renal failure therapy machine, an infusion pump, an oxygen sensor, a respiratory monitor, a glucose meter, a blood pressure monitor, an ECG monitor, a weighing scale, and a heart rate monitor.

[0016] According to a seventh aspect of this disclosure, which may be used in combination with any other aspects enumerated herein unless otherwise noted, a data field in the user interface is configured to receive at least one of the following: blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual replacement data, subjective data, or consumable data relating to consumable items.

[0017] Unless otherwise noted, according to the eighth aspect of this disclosure which may be used in combination with any other aspects enumerated herein, consumable items include at least one of filters, blood line sets, dialysate concentrate containers, blood anticoagulant containers, drug containers, disposable cassettes, adsorbent cartridges, and water purification containers.

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

[0019] According to a tenth aspect of this disclosure, which may be used in combination with any other aspects enumerated herein unless otherwise noted, a method for populating a patient medical record in a clinical database using recorded images includes transmitting a first message to a personal device prompting the patient to use the personal device's camera to record a first image of a medical device, and receiving the first image from the personal device. The method also includes determining, via a processor, first medical information indicating the type or model of a medical device from the first image, determining a data template and a second message associated with the determined type or model of the medical device, and transmitting a second message to the personal device via a processor prompting the patient to use the camera to record a second image of the medical device's screen. The method further includes receiving a second image from the personal device via a processor, extracting text from the second image via a processor, processing the extracted text using a data template via a processor, and categorizing the extracted text into fields. The method further includes writing at least a portion of the text from at least one of the fields to the patient medical record via a processor.

[0020] Unless otherwise noted, according to an eleventh aspect of this disclosure which may be used in combination with any other aspects enumerated herein, the method further includes, via a processor, determining a correspondence between one of the fields and a record field in the patient medical record, and via the processor, writing at least a portion of the text from the field to the record field in the patient medical record.

[0021] Unless otherwise noted, according to a twelfth aspect of this disclosure which may be used in combination with any other aspects enumerated herein, the method further includes determining a treatment time from a patient medical record via a processor and transmitting a first message prior to the treatment time via the processor.

[0022] According to a thirteenth aspect of this disclosure, which may be used in combination with any other aspects enumerated herein unless otherwise described, the method further includes, in a processor, receiving a treatment message from a personal device indicating that a patient should begin treatment, and transmitting a first message via the processor before treatment is initiated.

[0023] Unless otherwise noted, according to a fourteenth aspect of this disclosure, which may be used in combination with any other aspects enumerated herein, the first image is received in the processor via a first text message or a first short messaging service ("SMS") message, and the second image is received in the processor via a second text message or a second SMS message.

[0024] According to a 15th aspect of this disclosure, which may be used in combination with any other aspects enumerated herein unless otherwise noted, the method further includes, via a processor, converting at least a portion of the text from at least one of the fields to Health Level 7 ("HL7") format before writing it to a patient medical record.

[0025] Unless otherwise noted, according to a 17th aspect of the present disclosure which may be used in combination with any other aspects enumerated herein, the method further includes comparing, via a processor, at least a portion of text from at least one of the fields to a predetermined range, and, via the processor, writing, at least a portion of text from at least one of the fields if at least a portion of text from at least one of the fields is within the predetermined range.

[0026] Unless otherwise noted, according to a 17th aspect of this disclosure which may be used in combination with any other aspects enumerated herein, a system for transmitting information to a patient includes a patient home therapy machine configured to transmit therapeutic information, a medical record, and a clinician database configured to store a registration file which identifies the home therapy machine and the patient's personal device as registered devices and identifies whether the personal device has an application installed for viewing therapeutic and medical information. The system also includes a clinician server which is communicably coupled to the clinician database, the home therapy machine, and the personal device. The clinician server is configured to store therapeutic and medical information in the medical record, receive instructions that at least a portion of the therapeutic and medical information should be displayed on the personal device, and determine from the registration file whether an application is installed on the personal device. If an application is installed, the clinician server is configured to convert at least a portion of the therapeutic and medical information into an application format for display within the application and to transmit at least a portion of the converted therapeutic and medical information to the personal device. If the application is not installed, the clinician server is configured to convert at least a portion of the treatment and medical information into text message or short messaging service ("SMS") format and transmit at least a portion of the converted treatment and medical information to a personal device via one or more text messages or SMS messages.

[0027] Unless otherwise noted, according to Aspect 18 of this Disclosure, which may be used in combination with any other aspects listed herein, the application format includes at least one of the Extended Markup Language ("XML") format or the Hypertext Markup Language ("HTML") format.

[0028] According to a nineteenth aspect of the present disclosure, which may be used in combination with any other aspect recited herein unless otherwise stated, the instruction that at least a portion of treatment information and medical information should be displayed on a personal device includes at least one of a message from an application or a text / SMS message from the personal device.

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

[0030] According to a twenty - first aspect of the present disclosure, which may be used in combination with any other aspect recited herein unless otherwise stated, the home therapy machine is configured to store a prescription using two programs, each of the programs providing parameters for operating the home therapy machine to perform a treatment, and the clinician server is configured to receive a program message from the personal device indicating a change from the first program to the second program and transmit program instructions for changing from the first program to the second program to the home therapy machine.

[0031] In a twenty - second aspect of the present disclosure, any of the structures and functionalities disclosed in relation to FIGS. 1 - 33 may be combined with any other structures and functionalities disclosed in relation to FIGS. 1 - 33.

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

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

[0034] A further advantage of the present disclosure is to provide improved clinician or caregiver efficiency.

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

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

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

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

[0039] Furthermore, an advantage of this disclosure is that it reduces the waste of disposable sets and other auxiliary textile products resulting from disposal, which often occurs when the machine timer ends.

[0040] The advantages discussed herein may be found in one or more of the embodiments disclosed herein, and perhaps not in all of them. Additional features and advantages will be described herein and will become apparent from the embodiments and drawings for carrying out the invention described below. The present invention further provides, for example, the following: (Item 1) A machine-accessible device that stores instructions, wherein, when executed, the instructions cause the machine to input data into a patient medical record of a clinical system, and inputting data into the patient medical record is Operate the camera and record images, To operate the display interface, The operation of a connection interface configured to connect to a clinician database, wherein the clinician database is configured to store patient medical records, To operate the processor and acquire medical information and Therefore, Obtaining the aforementioned medical information means The display interface is used to display a user interface with fields into which medical information should be entered. After selecting a data field in the user interface, the display interface graphically provides a first option for inputting medical information from an image and a second option for inputting medical information via text input. If the first option is selected, Receiving images recorded from the aforementioned camera, wherein the recorded images include a medical device or the screen of a medical device. Extracting text from the aforementioned image, The display interface enables the selection of at least a portion of the text from the image, The selected text from the image is written as medical information to the data field of the user interface. To do, If the second option is selected, the display interface will enable text input of the data field as medical information, After the transmission command is received, the medical information written in the data field is transmitted to the patient medical record stored in the clinician database. A machine-accessible device. (Item 2) The machine-accessible device further comprises instructions stored in the machine-accessible device, the instructions being configured, when executed, to cause the machine to operate the processor, the processor Determining a data template for the extracted text on the image, Using the aforementioned data template, the extracted text is processed and the extracted text is categorized into fields. Allow selection of at least one of the fields, and write the selected text from the image to the data field of the user interface. A machine-accessible device as described in item 1, which performs the following actions. (Item 3) The machine-accessible device according to item 2, wherein the data template is configured to define the context of the extracted text in relation to the text location in the image. (Item 4) The machine-accessible device according to item 2, further comprising instructions stored in the machine-accessible device, the instructions, when executed, are configured to cause the machine to operate the processor, the processor determining the data template based on (i) selection of a medical device type via the user interface, (ii) information scanned from identifiers located on the medical device, and (iii) at least one of signs in the extracted text, or (iv) the relative arrangement of the extracted text. (Item 5) The machine-accessible device described in item 4, wherein the identifier located on the medical device includes at least one of a quick response ("QR") code, barcode, serial number, or hardware number located on the housing of the medical device or on the screen of the medical device. (Item 6) The medical device is a machine-accessible device as described in item 1, including at least a renal failure therapy machine, an infusion pump, an oxygen sensor, a respiratory monitor, a glucose meter, a blood pressure monitor, an ECG monitor, a weighing scale, and a heart rate monitor. (Item 7) The machine-accessible device according to item 1, wherein the data field of the user interface is configured to receive at least one of the following: blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual replacement data, subjective data, or consumable data relating to consumable items. (Item 8) The consumable items include at least one of the following: filters, blood line sets, dialysis fluid concentrate containers, blood anticoagulant containers, drug containers, disposable cassettes, adsorbent cartridges, and water purification containers, as described in item 7, for the mechanically accessible device. (Item 9) The machine is a personal mobile communication device, as described in item 1. (Item 10) A method for inputting data into a patient medical record in a clinical database using recorded images, wherein the method is: The method involves 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, Receiving the first image from the personal device, The processor determines first medical information indicating the type or model of the medical device from the first image, The processor determines a data template and a second message associated with the determined type or model of the medical device, The process involves transmitting the second message to the personal device via the processor, wherein the second message prompts the patient to use the camera to record a second image on the screen of the medical device. The processor receives the second image from the personal device, The process involves extracting text from the second image via the aforementioned processor, The extracted text is processed using the data template via the aforementioned processor, and the extracted text is classified into fields. To write at least a portion of the text from at least one of the fields to the patient medical record via the processor. Methods that include... (Item 11) The processor determines the correspondence between one of the fields and the recorded field in the patient medical record, The process involves writing at least a portion of the text from the field to the record field in the patient medical record via the processor. The method described in item 10, further including the method described in item 10. (Item 12) The processor is used to determine the treatment time from the patient's medical records, The first message is transmitted via the processor before the treatment time. The method described in item 10, further including the method described in item 10. (Item 13) The processor receives a treatment message from the personal device indicating that the patient should begin treatment. The first message is transmitted via the processor before the treatment is initiated. The method described in item 10, further including the method described in item 10. (Item 14) The method according to item 10, wherein the first image is received by the processor via a first text message or a first short messaging service ("SMS") message, and the second image is received by the processor via a second text message or a second SMS message. (Item 15) The method of item 10, further comprising converting at least a portion of the text from at least one of the fields to Health Level 7 ("HL7") format before writing it to the patient medical record via the processor. (Item 16) The process involves comparing at least a portion of the text from at least one of the fields with a predetermined range via the processor, If, via the processor, at least a portion of the text from at least one of the fields is within the predetermined range, then at least a portion of the text from at least one of the fields is written. The method described in item 10, further including the method described in item 10. (Item 17) A system for transmitting information to a patient, wherein the system is The patient's home therapy device configured to transmit treatment information, A clinician database configured to store the aforementioned medical records and registration files, wherein the registration files identify the home therapy machine and the patient's personal device as registered devices, and identify whether the personal device has an application installed for viewing the treatment information and the medical information. The clinician database, the home therapy machine, and the clinician server which is communicably connected to the personal device. Equipped with, The aforementioned clinician server The treatment information and medical information are stored in the medical record, Receiving instructions that at least a portion of the aforementioned treatment information and medical information should be displayed on the personal device, From the registration file, determine whether the application is installed on the personal device, If the aforementioned application is installed, Converting at least a portion of the aforementioned treatment information and medical information into an application format for display within the application, Transmitting the aforementioned treatment information and at least a portion of the converted medical information to the personal device. To do, If the aforementioned application is not installed, Converting the aforementioned treatment information and at least a portion of the aforementioned medical information into text message or short messaging service ("SMS") format, Transmitting the treatment information and at least a portion of the converted medical information to the personal device via one or more text messages or SMS messages. To do A system configured to perform the following actions. (Item 18) The system described in item 17, wherein the application format includes at least one of the Extended Markup Language ("XML") format or the Hypertext Markup Language ("HTML") format. (Item 19) The instruction that at least a portion of the treatment information and medical information should be displayed on the personal device is a system according to item 17, which includes at least one of a message from the application or a text / SMS message from the personal device. (Item 20) The registration file is the system described in item 17, included in the medical record. (Item 21) The home therapy machine is configured to store prescriptions using two programs, each of which provides parameters for operating the home therapy machine to perform treatment, and the clinician server, Receiving a program message from the personal device indicating a change from the first program to the second program, Transmitting program instructions to the home therapy machine to change from the first program to the second program. The system described in item 17 is configured to perform the following actions. [Brief explanation of the drawing]

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

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

[0043] [Figure 3] Figure 3 is a perspective view illustrating a blood set for use in conjunction with one embodiment of the medical fluid delivery machine of Figure 2, according to one embodiment of the present disclosure.

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

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

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

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

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

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

[0050] [Figure 10] Figure 10 shows a second embodiment of the medical fluid data transfer system.

[0051] [Figure 11] Figure 11 shows a schematic diagram illustrating the application operation module in the clinician server of the medical fluid data transfer system of Figure 10, according to one embodiment of the present disclosure.

[0052] [Figure 12] Figure 12 shows a schematic diagram illustrating communication between the home therapy machine of Figures 10 and 11, a personal mobile communication device, and a clinician server, according to an exemplary embodiment of the present disclosure.

[0053] [Figure 13] Figure 13 illustrates an exemplary patient data structure stored on the clinician database of the medical fluid data transfer system of Figure 10, according to an exemplary embodiment of the present disclosure.

[0054] [Figure 14] Figures 14 and 15 show schematic diagrams illustrating the user interface of the application of Figure 11 according to exemplary embodiments of the present disclosure. [Figure 15] Figures 14 and 15 show schematic diagrams illustrating the user interface of the application of Figure 11 according to exemplary embodiments of the present disclosure.

[0055] [Figure 16] Figure 16 is a schematic diagram of a personal mobile communication device according to an exemplary embodiment of the present disclosure, as shown in Figures 10 and 11.

[0056] [Figure 17] Figure 17 illustrates a schematic diagram of a data template according to an exemplary embodiment of the present disclosure.

[0057] [Figure 18] Figure 18 shows a schematic diagram illustrating writing to the data field of the user interface of Figure 14 according to an exemplary embodiment of the present disclosure.

[0058] [Figure 19] Figure 19 is a flowchart illustrating an exemplary procedure for inputting medical information from images using the personal mobile communication device applications of Figures 10 and 11, according to an exemplary embodiment of the present disclosure.

[0059] [Figure 20] Figure 20 shows an example of a user interface that can be displayed by an application on a personal mobile communication device of Figures 10 and 11, enabling a patient to provide recorded images, according to an exemplary embodiment of the present disclosure.

[0060] [Figure 21] Figure 21 shows a schematic diagram of a patient medical template used by the clinician server in Figures 10 and 11 to populate data fields in a patient's medical record, according to an exemplary embodiment of the present disclosure.

[0061] [Figure 22] Figure 22 is a schematic diagram of the data acquisition module of the clinician server shown in Figure 11, according to an exemplary embodiment of the present disclosure.

[0062] [Figure 23]Figures 23 and 24 are flowcharts of an exemplary procedure for populating a medical device template in Figure 21 with images (and / or text messages received therefrom) recorded by the personal mobile communication devices in Figures 10 and 11, according to an exemplary embodiment of the present disclosure. [Figure 24] Figures 23 and 24 are flowcharts of an exemplary procedure for populating a medical device template in Figure 21 with images (and / or text messages received therefrom) recorded by the personal mobile communication devices in Figures 10 and 11, according to an exemplary embodiment of the present disclosure.

[0063] [Figure 25] Figure 25 shows a schematic diagram of a clinician server hosting a website or file transfer site for receiving medical information via images from the personal mobile communication devices of Figures 10 and 11, according to an exemplary embodiment of the present disclosure.

[0064] [Figure 26] Figures 26-29 show schematic diagrams of a personal mobile communication device displaying medical information provided by the clinician server of Figures 10 and 11, according to exemplary embodiments of the present disclosure. [Figure 27] Figures 26-29 show schematic diagrams of a personal mobile communication device displaying medical information provided by the clinician server of Figures 10 and 11, according to exemplary embodiments of the present disclosure. [Figure 28] Figures 26-29 show schematic diagrams of a personal mobile communication device displaying medical information provided by the clinician server of Figures 10 and 11, according to exemplary embodiments of the present disclosure. [Figure 29] Figures 26-29 show schematic diagrams of a personal mobile communication device displaying medical information provided by the clinician server of Figures 10 and 11, according to exemplary embodiments of the present disclosure.

[0065] [Figure 30]Figure 30 shows a schematic diagram of a personal mobile communication device of Figures 10 and 11 that prompts a patient for medical information, according to an exemplary embodiment of the present disclosure.

[0066] [Figure 31] Figure 31 shows a schematic diagram of the personal mobile communication device of Figures 10 and 11, which provides a program for a patient to choose a medical treatment, according to an exemplary embodiment of the present disclosure.

[0067] [Figure 32] Figure 32 shows a schematic diagram of the personal mobile communication device of Figures 10 and 11 that provides educational content to a patient, according to an exemplary embodiment of the present disclosure.

[0068] [Figure 33] Figure 33 shows a schematic diagram of the personal mobile communication device of Figures 10 and 11 that provides a video chat session between a patient and a clinician, according to an exemplary embodiment of the present disclosure. [Modes for carrying out the invention]

[0069] A medical fluid delivery system is disclosed herein. An exemplary medical fluid delivery system is configured to enhance patient engagement with medical treatments, such as medical fluid delivery therapy. The medical fluid delivery system is configured to provide the patient with greater transparency regarding their treatment and at least some degree of control over directing their treatment, while also providing resources to educate or otherwise assist the patient throughout the treatment process. The exemplary medical fluid delivery system is configured to provide patient engagement regardless of the type or set of features of the medical devices or the patient's personal mobile communication devices associated with the treatment. Such a configuration allows the disclosed medical fluid delivery system to be adapted to virtually any patient situation.

[0070] In some embodiments, a medical fluid delivery system includes a personal mobile communication device, a medical fluid delivery machine, and a clinician server / database. Exemplary personal mobile communication devices and medical fluid delivery machines are located in the patient's home and / or in a self-service healthcare facility. The clinician server is communicably coupled to the personal mobile communication device and / or medical fluid delivery machine via a wide-area network (i.e., the Internet). The clinician server is configured as a hub, which enables the personal mobile communication device to provide features designed to engage the patient with medical fluid delivery therapy.

[0071] As disclosed herein, an exemplary clinician server receives medical fluid delivery data (e.g., treatment information) from a medical fluid delivery machine, and the delivery data 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, enabling the patient to track their treatment progress. In addition, the patient may use the personal mobile communication device to change (or request) a treatment program. The request is routed through the clinician server to verify that the change is appropriate before being transmitted to the medical fluid delivery machine.

[0072] An exemplary clinician server operates in conjunction with a personal mobile communication device to enable patients to effortlessly provide medical information such as vital sign data and medical device data. The personal mobile communication device is configured to allow patients to manually input data, record photos including data from connected medical devices such as scales, blood pressure monitors, thermometers, and glucose meters, and / or receive data wirelessly from there. The collected data is stored in the patient's medical record. In some embodiments, the clinician server and / or the personal mobile communication device may use templates to determine how the received data should be automatically populated into the patient's medical record.

[0073] As disclosed herein, personal mobile communication devices may include feature-rich smart devices such as smartphones or tablet computers. Smart devices may run specialized applications (e.g., “apps”) defined by instructions stored in memory. The execution of the stored instructions causes the application to run on the smart device's processes, and the application is configured to improve patient involvement in medical treatment. In some cases, personal mobile communication devices may include feature-less conventional cellular phones, which have considerably less processing power and features compared to smart devices. Cellular devices may operate using text messages and / or specialized applications (e.g., apps) defined by instructions stored in memory. Applications for feature-less devices may have fewer features compared to applications for smart devices.

[0074] The following disclosure is separated into two sections. Section 1 discloses an embodiment of a medical fluid delivery system. Section 2 discloses features that enable the medical fluid delivery system to improve patient engagement and / or compliance with medical treatment.

[0075] (I. Embodiments of Medical Fluid Delivery Systems) An exemplary 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. In relation to renal failure treatment machines, the patient's renal system is unable to function due to various causes. Renal failure results in several physiological disturbances. Maintaining fluid and mineral balance or excreting the daily metabolic load is no longer possible. Toxic end products of nitrogen metabolism (urea, creatinine, uric acid, and others) can accumulate in the blood and tissues.

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

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

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

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

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

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

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

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

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

[0085] Any of the above modalities performed by machines may be performed on a schedule and may require a startup procedure. For example, dialysis patients typically undergo treatment on a schedule, such as every other day or daily. Hematology machines typically require a certain amount of time before treatment for setup, such as performing disinfection procedures. Patients undergoing these modalities may lead busy lives and have plans or errands to run on the days when treatment is scheduled.

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

[0087] In one particular example, a home-based therapeutic device may reuse certain components by disinfecting them between treatments. This device may employ one or more disinfection timers, which require the patient or caregiver to begin treatment using the device before the disinfection timer expires. Otherwise, the patient would need to wait until another disinfection procedure is completed before beginning treatment. In one embodiment, the home-based therapeutic device communicates a treatment start time deadline via the device's graphical user interface, which requires the patient to be near the device to access the start time deadline and respond accordingly.

[0088] It should be understood that this disclosure applies to any type of disinfection, such as hot water disinfection and chemical disinfection. In this regard, this disclosure is not limited to home treatment machines; for example, in-center machines are typically chemically disinfected, and in-center machines may set treatment start deadlines after such disinfection. Furthermore, this disclosure is not limited to start time deadlines based on disinfection, but may also apply to other start time deadlines, such as those based on the completion of priming. Moreover, this disclosure is not limited to initial start time deadlines. For example, most machines will allow the patient to temporarily discontinue treatment, disconnect from the machine, and perform certain necessary actions away from the machine. With regard to hematology, the machine may or may not typically enema the blood back to the patient and circulate the dialysis fluid for a period of time. In either case, the time during which the patient may be temporarily disconnected from the machine is not unlimited, and it is assumed that this disclosure also applies to return time limits.

[0089] 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 smartphone. In one embodiment, the App is provided via a middleware software application, an example of which is discussed in detail below. In an alternative embodiment, the software is configured to communicate with the patient's and / or caregiver's personal mobile communication device, e.g., a smartphone, using text messaging features directly through a middleware software application. In either case, the App or text messages are constructed, in one embodiment, to remind the patient of any imminent deadlines without connecting the patient to a machine, enabling the patient and / or caregiver to track when treatment needs to be initiated.

[0090] Alternatively, or in addition, it is conceivable to construct communication software to automatically program reminders on the user's mobile communication device, for example, on the device's inherent task tracking features, such as a calendar application. Most smartphones are provided with a calendar that divides each day into time segments, such as hours. The software of the system and methodology of this disclosure may be programmed to access the smartphone calendar of an authorized patient and / or caregiver and to input appropriate information, such as a machine starting or completing disinfection within the appropriate time segment of the appropriate day.

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

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

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

[0094] Referring here to the drawings, in particular Figure 1, a medical fluid data transfer system 10 operating within a medical fluid delivery machine 90 is illustrated. System 10 incorporates many medical fluid delivery machines 90 (one type of which will be discussed in detail below). The machines 90 of the data transfer system 10 may be of the same type (e.g., all HD machines) or of different types (e.g., a mixture of HD, PD, CRRT, and medical or nutritional fluid delivery).

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

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

[0097] The connection server 118 communicates with the medical fluid delivery machines 90 via the medical device system hub 120. The system hub 120 enables data and information about each home treatment machine 90 and its peripherals to be exchanged between the machines 90 and other clients connected to the server 118 via the 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, in a clinic or hospital 126a-126n.

[0098] Electronic medical record ("EMR") databases in clinics or hospitals 126a-126n store electronic information about patients. System hub 120 transmits data collected from log files of machine 90 to hospital or clinic databases 126a-126n, which may merge or supplement the medical records of those patients. Databases in clinics or hospitals 126a-126n may contain patient-specific treatment and prescription data, and therefore access to such databases may be highly restricted. Enterprise resource planning system 140 retrieves and compiles data generated via patient and clinician website access, such as complaints, billing information, and lifecycle management information. Web portal 150 enables patients and clinics 152a-152n treating patients to access a publicly available website for users of medical fluid delivery machine 90. Business intelligence portal 160 collects data from system hub 120 and provides the data to marketing 162, research and development 164, and quality / pharmaceutical safety monitoring 166.

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

[0100] In one embodiment, the home treatment device 90 provides home treatment, such as home hemodialysis, to the patient at their home, and then reports the results of the treatment to the clinician, physician, and nurse involved in managing the patient's health and well-being.

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

[0102] In one embodiment, the home healthcare device 90 uses a connectivity service, for example, via the Internet, to transfer data between the modem 102 and the system hub 120. Here, a dedicated line may be provided at each patient's home to connect the home healthcare device 90 to the connectivity server 118 via the modem 102. In one embodiment, the home healthcare device 90 accesses the Internet using a separate, for example, 3G, 4G, or 5G modem 102. The modem 102 may use an Internet Service Provider (ISP) such as Vodafone®. In one implementation, a connectivity agent 114 developed by the connectivity service provider (e.g., the provider of the connectivity server 118) is installed on the home healthcare device 90 and started on the device's ACPU 50. One preferred connectivity service is provided by Axeda®, which provides a securely managed connection 116 between the medical device and the connectivity server 118.

[0103] The connection agent 114 enables the home healthcare machine 90 to connect to the connection server 118 and transfer data to and from the connection server 118. The connection service operating through the agent 114 and server 118 ensures that the connection with the machine 90 is secure, that data passes correctly through the machine 90's firewall, checks for data or system crashes, and ensures that the connection server 118 is communicating with the correct home healthcare machine 90.

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

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

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

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

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

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

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

[0111] A primary control processor ("ACPU") or control unit 50 includes one or more processors and memory. The control unit 50 receives air detection signals from air detectors 22a and 22v (and other sensors in system 10 such as temperature sensors, blood leak detectors, conductivity sensors, pressure sensors, and access disconnect transducers 86, 88, etc.) and controls components such as line clamps 18a and 18v, blood pump 30, heparin pump 26, dialysis fluid pumps 64 and 96, and valves 32i, 32o, 34i, 34o, 68i, 68o, 98i, and 98o. Blood exiting the hemofilter 40 via the venous line 16 flows through the air trap 28. The air trap 28 removes air from the blood before the dialyzed blood is returned to the patient 12 via the venous line 16.

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

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

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

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

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

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

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

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

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

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

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

[0123] Figure 3 illustrates that the machine 90 of Figure 2 may operate with a blood set 100. The blood set 100 includes an arterial line 14, a venous line 16, a heparin vial 24, a heparin pump 26 / blood pump 30, and a hemofilter 40 (e.g., a dialyzer). An air trap 28 may be located in the venous line 16 to remove air from the blood before it is returned to the patient 12. Air detectors 22a and 22v contact the arterial and venous lines 14 and 16, respectively, for operation.

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

[0125] (B. Exemplary Connectivity Embodiments of Medical Fluid Delivery Systems) Referring now to Figure 4, System 110a of the present disclosure is illustrated. In the illustrated embodiment, System 110a operates in conjunction with System 10 described above, which 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 illustrated in Figure 4 as part of a cloud environment. Each of the connection server 118, system hub 120, service portal 130, enterprise resource planning system 140, web portal 150, and business intelligence portal 160 may be part of a cloud environment or reside on one or more dedicated servers.

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

[0127] The medical fluid delivery machines 90a and 90b are connected to the connection server 118 via a securely managed connection 116 as described above. To do so, the machines 90a and 90b are connected to the internet 52 via, for example, a modem 102 as discussed above. In one embodiment, the system hub 120 stores middleware software that can be accessed by mobile communication devices 200a and 200b (collectively referred to as device 200 in this specification, or generally, individually referred to as device 200). The mobile communication devices 200a and 200b may be, for example, smartphones running on Android®, iOS®, Windows® Phone®, BlackBerry®, Sailfish OS®, Tizen®, or Ubuntu Touch® operating systems. The mobile communication devices 200a and 200b may belong to patients 12a and 12b, respectively, and / or to clinicians 112a and 112b, respectively. Mobile communication devices 200a and 200b, as illustrated in Figure 4, are also connected to the internet 52.

[0128] In one embodiment, mobile communication devices 200a and 200b download application software ("app") from middleware software stored on the system hub 120 via their connection to the internet 52. The app is updated whenever there is a change in the state of the corresponding machine 90a or 90b. For example, a medical fluid delivery machine 90a may have just completed its automated self-test routine and is now ready to perform a disinfection procedure. Machine 90a may generate a code that identifies this state and send it to middleware software stored on the system hub 120. The middleware software then, for example, using a lookup table, converts the code into a message such as "Self-test complete, ready to disinfect" and displays the message on the app downloaded on the mobile communication device 200a of the patient 12a or clinician 112a. Along with the message, the app may be programmed to provide a visual identifier, such as an icon, associated with the specific state to which machine 90a belongs. The app may also provide one or more audio alerts, such as a "ringing" sound, and / or tactile alerts, such as vibrations, which prompt the patient 12a or clinician 112a to view the app and check for changes in the status of the machine 90.

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

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

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

[0132] Referring now to Figure 5, System 110b of the present disclosure is illustrated. In the illustrated embodiment, System 110b operates in conjunction with System 10 described above, which includes a connection server 118, a system hub 120, a service portal 130, a corporate resource planning system 140, a web portal 150, and a business intelligence portal 160, which are illustrated in Figure 5 as part of a cloud environment, but may instead reside on one or more dedicated servers. Other components of System 10 not shown in Figure 5 may also be part of System 110a. A single medical fluid delivery machine 90 is illustrated for ease of illustration, however, multiple medical fluid delivery machines 90 may also be connected to System 110b. The medical fluid delivery machine 90 may be located in the home of a patient 12 (illustrated as being outside the home) or in clinics 126a-126n for a clinician 112. The medical fluid delivery machine 90, again in the illustrated embodiment, is connected to the connection server 118 via a securely managed connection 116 and an Internet 52 connection, for example, using a modem 102.

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

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

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

[0136] The middleware software stores each of the phone numbers of each mobile communication device 200 and matches each of those numbers with machine 90. When an event code is sent from machine 90 to the middleware software as described above, the middleware software finds the phone number of the mobile communication device 200 associated with that machine, converts the code into an appropriate message using, for example, a lookup table as described above, and sends the converted message to the called phone number. It is assumed that multiple communication devices 200 may be associated with the same medical fluid delivery machine 90. For example, in any of the clinics 126a-126n, the phone numbers of multiple doctors, nurses, and / or clinicians may be associated with the same machine 90. In a home setting, the phone numbers of patient 12 and the patient's clinician and / or caregiver assistant may be associated with the same machine 90.

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

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

[0139] In another example, the medical fluid delivery machine 90 may be pre-programmed to begin treatment at 3:00 p.m. The medical fluid delivery machine 90 may again require 3 hours for self-testing and disinfection. The patient 12 or clinician 112 therefore needs to be near the machine 90 by noon to begin pre-treatment. In one embodiment, the patient 12 or clinician 112 makes a setting with the machine 90 regarding how far in advance (e.g., 2 hours) the patient 12 or clinician 112 should be notified or alerted. Here, the machine 90 generates a code at 10:00 a.m. and sends the code to middleware software stored on the system hub 120. The middleware software then uses, for example, a lookup table to translate the code into a message such as "Begin preparing for treatment in 2 hours," and causes, for example, the cellular output routine discussed above to send the text message to the patient 12 or clinician 112's mobile communication device 200, displaying the message along with an audio alert, such as a "ringing" sound, and / or a tactile alert, such as vibration, prompting the patient 12 or clinician 112 to view the notification.

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

[0141] Referring now to Figure 6, System 110c of the present disclosure is illustrated. In the illustrated embodiment, System 110c operates in conjunction with System 10 described above, which includes a connection server 118, a system hub 120, a service portal 130, a corporate resource planning system 140, a web portal 150, and a business intelligence portal 160, which are illustrated in Figure 6 as part of a cloud environment, but may instead reside on one or more dedicated servers. Other components of System 10 not shown in Figure 6 may also be part of System 110a. A single medical fluid delivery machine 90 is illustrated for ease of illustration, however, multiple medical fluid delivery machines 90 may also be connected to System 110b. The medical fluid delivery machine 90 may be located in the home of a patient 12 (illustrated as being outside the home) or in clinics 126a-126n relating to a clinician 112. The medical fluid delivery machine 90, again in the illustrated embodiment, is connected to the connection server 118 via a securely managed connection 116 and an Internet connection 52, for example, using a modem 102. In Figure 6, the connection server 118 and the securely managed connection 116 are used for bidirectional communication.

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

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

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

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

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

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

[0148] In an alternative embodiment, patient 12 or clinician 112 may enter a known code in a text message to select a specific action to be performed in machine 90, for example, a self-test routine or a disinfection procedure. The code may be a suggestive code such as "self-test" or "disinfect." The text message is sent via the cellular network 210 to middleware software in system hub 120. The middleware software converts the text code to an action code for the selected action, for example, via a lookup table. Alternatively, the code entered by patient 12 or clinician 112 may be an action code that does not require any conversion. In either case, the action code is sent via connection server 118 and securely managed connection 116 to machine 90 with its connection agent 114 turned on, enabling the action code for the selected action to be sent to the machine's ACPU 50, which then initiates the execution of the selected action.

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

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

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

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

[0153] With respect to systems 110a-110c, it is assumed that the app on the mobile communication device 200 is programmed to be configurable by the user to select the types of notifications that the user wishes to receive on those devices 200, for example, via the app itself, via text messages, and / or via calendar notifications. In one embodiment, the system hub 120 may send all notification types, and the mobile communication device 200 will ignore communication types that the user has disabled. In another embodiment, the system hub 120 remembers the user's preferences and sends only information in the selected notification types.

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

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

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

[0157] In an alternative embodiment, clinics 126a-126n may each maintain their own local area network, each operating with the local system hub 220. App 230 may again be developed by product development 128 (Figure 1) and delivered via the service portal 130 to the local system hub 220 of clinics 126a-126n, which operate with the entire system 10. Each nurse, clinician, or physician 112 authorized to download App 230 does so from the local system hub 220. The local system hub 220 then maintains middleware software to operate with App 230 in the manner described above with respect to the system hub 120 in systems 110a-110c. In a further alternative embodiment, App 230 may be developed by clinic 126a-126n and stored on its local system hub 220.

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

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

[0160] With respect to the countdown timer, it is assumed that the connection agent 114 enables machines 90a-90n to send remaining time data to the system hub 120, thereby allowing the app 230 to display the actual remaining time for each machine 90 undergoing the timed process. The app 230 anticipates alarms or other delays that the machine 90 may experience. During an alarm situation, the corresponding icons 190a-190f may display a message such as "Alarm" or "Safe Mode". A nurse, clinician, or physician 112 may then select the countdown time in Figure 9 to return to the home icons 190c, 190d, and 190h illustrated in Figure 7.

[0161] Nurses, clinicians, or physicians 112 may toggle an alert on / off icon 238 to enable or disable status changes concerning machines 90a-90n to be alerted visually, audibly, and / or tactilely. When the alert on / off icon 238 is switched to “on”, the app 230 on the mobile communication device 200 will provide visual, audible, and / or tactile alerts whenever the status of the machine changes, for example, (i) “Self-testing started”, (ii) “Self-testing completed”, (iii) “Disinfection started”, (iv) “Disinfection completed”, (v) “Treatment started”, (vi) “Treatment completed”. In one embodiment, codes relating to (i)-(v) are transmitted via machines 90a-90n through securely managed connections 116, connection servers 118, and system hubs 120 or local system hubs 220, translated by middleware software, and forwarded to app 230, which updates the appropriate icon 190. In various embodiments, "(vi) Treatment complete" can be inferred (a) via machines 90a-90n using an activated connection agent 114, or (b) when the countdown timer for the appropriate icons 190a-190n expires, and the connection agent 114 may still be off.

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

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

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

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

[0166] The procedure described herein for the action button 240 is also implemented in system 110c and may be implemented for other machine commands which may vary depending on the type of machine 90. It is also assumed that a clinic 126a may determine that it is sufficiently safe to leave the connection agent 114 on during treatment or part of treatment by one or more nurses, clinicians, or physicians 112 present in the clinic. In such cases, the nurses, clinicians, or physicians 112 may control in-treatment activities with respect to the machine 90. For example, the nurses, clinicians, or physicians 112 may receive and respond to alarms / alerts via the app 230 on the mobile connection device 200, start and stop the pump and other aspects of treatment, start and stop disinfection, start and stop priming, etc.

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

[0168] In one embodiment, when a mobile communication device 200 transmits data to a system hub 120 or local system hub 220 for delivery to a machine 90, the data is provided with a mobile communication device 200 identifier that identifies the mobile communication device 200 that transmitted the data. The system hub 120 or local system hub 220 may or may not convert the data from the mobile communication device 200, as discussed above, but in either case, the mobile communication device 200 identifier is maintained for the connection server 118. For each mobile communication device 200, the connection server 118 knows which machine 90 should receive the converted data, for example, and transmits the converted data to each associated communication device 200. Once delivered to the machine 90, the connection server 118 may remove the mobile communication device 200 identifier from the data, as it is no longer needed.

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

[0170] (II. Patient Involvement Mechanisms) The exemplary medical fluid delivery data transfer system 10 disclosed above in relation to Figure 1-9 is configured to improve patient engagement with medical fluid delivery therapies such as dialysis, renal failure, and / or peritoneal therapy. Figure 10 shows an exemplary medical fluid data transfer system 1000, similar to the medical fluid data transfer system 10 discussed in relation to Figure 1-9, according to an exemplary embodiment of the present disclosure. The exemplary medical fluid data transfer system 1000 (e.g., a mobile platform) is configured to improve patient engagement with and / or compliance with therapy by providing features for controlling and reporting therapy-related information to patients to improve therapy transparency, and / or providing access to educational materials and / or real-time assistance from clinicians.

[0171] An exemplary medical fluid data transfer system 1000 includes, for example, a personal mobile communication device 200a operated by a patient. The medical fluid data transfer system 1000 also includes a blood pressure monitor 104, a measuring device 106, and a home therapy machine 90, similar to the respective devices discussed above in relation to Figure 1-9. The personal mobile communication device 200a, the home therapy machine 90, the blood pressure monitor 104, and the measuring device 106 may be located, for example, in the patient's home, a self-service clinic, and / or a serviced medical clinic.

[0172] The home therapy machine 90 may include any type of hemodialysis machine, peritoneal dialysis machine, CRRT machine, drug and / or nutritional fluid delivery machine, and combinations thereof. The home therapy machine 90 may, for example, provide continuous circulating peritoneal dialysis ("CCPD"), tidal flow automated peritoneal dialysis ("APD"), and continuous flow peritoneal dialysis ("CFPD"). Typically, the home therapy machine 90 may automatically perform draining, refilling, and retention cycles while the patient is asleep.

[0173] The peritoneal dialysis fluid may comprise a solution or mixture containing 0.5% to 10%, preferably 1.5% to 4.25%, of glucose (or more generally, saturates). The peritoneal dialysis fluid may include, for example, the Dianeal®, Physioneal®, Nutrineal®, and Extranal® dialysis fluids commercially available from the assignees of this disclosure. The dialysis fluid may also, or alternatively, comprise a certain percentage of icodextrin.

[0174] In both hemodialysis and peritoneal dialysis, "adsorbent" technology can be used to remove uremic toxins from waste dialysate and reinject therapeutic agents (ions and / or glucose, etc.) into the treated fluid, allowing the fluid to be reused to continue dialysis for the patient. One commonly used adsorbent is made from zirconium phosphate, which is used to remove ammonia generated from the hydrolysis of urea. Typically, large amounts of adsorbent are needed to remove the ammonia generated during dialysis treatment.

[0175] An exemplary weighing scale 106 includes any device configured to measure the mass of a patient or therapeutic component. For example, weighing scale 106 may measure a patient's weight before, during, and / or after renal failure therapy. In addition, or alternatively, weighing scale 106 may measure supply or drainage bags to track renal failure therapy. Specifically, weighing scale 106 may be used to measure the amount of UF removed or the amount of fluid supplied to the patient. Weighing scale 106 may display a digital value indicating the weight. Alternatively, weighing scale 106 may display a physical scale or dial aligned with markers to indicate the measured weight. In some embodiments, weighing scale 106 may store pre-treatment, during, and / or post-treatment weight values ​​in separate windows so that patient input is required to view all values ​​when medical information is recorded.

[0176] An exemplary blood pressure monitor 104 includes any device configured to measure a patient's blood pressure and / or pulse. For example, the blood pressure monitor 104 may measure a patient's blood pressure before, during, and / or after renal failure therapy. The blood pressure monitor 104 may display a digital value indicating the patient's blood pressure. Alternatively, the blood pressure monitor 104 may display a physical scale with a dial aligned with a numerical value to indicate the measured blood pressure. In some embodiments, the blood pressure monitor 104 may store pre-treatment, during, and / or post-treatment blood pressure values ​​in a separate window so that when medical information is recorded, patient input is required to view all values. The blood pressure monitor 104 may be integrated with a home therapy machine 90. In another embodiment, the blood pressure monitor 104 may include a wearable sensor such as a smartwatch or fitness tracking device.

[0177] In addition to obtaining medical information (e.g., medical device data) from medical devices 90, 104, and 106, the exemplary personal mobile communication device 200a may also obtain medical information from patients and / or therapeutic consumable items 1006. Figure 10 shows examples of consumable items 1006, including, for example, renal failure therapeutic medical device filters, disposable cassettes, blood line sets, drug delivery line sets, and containers (e.g., dialysate concentrate containers, anticoagulant containers, drug containers, and / or water purification containers). Consumable items 1006 may also include adsorbent cartridges or any other disposable or material sources for medical treatment. Consumable items may include identifiers 1008 configured to provide medical information in the form of consumable information or consumable data. For example, identifiers 1008 may include information identifying the type of consumable item, serial number, and / or characteristics of the consumable item. In some cases, consumable items 1006 may also include labels containing medical information such as chemical composition characteristics. The patient or clinician uses a personal mobile communication device 200a to record images of identifier 1008, images of labels on consumable item 1006, and / or images of consumable item 1006 itself, to document the substances used during treatment.

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

[0179] Collectively, the blood pressure monitor 104 and the weighing device 106 are referred to as medical devices. It should be understood that the medical fluid data transfer system 1000 may include additional medical devices such as infusion pumps (e.g., syringe pumps, linear peristaltic pumps, large-volume pumps ("LVP"), portable pumps, multi-channel pumps), oxygen sensors, respiratory monitors, glucose meters, blood pressure monitors, electrocardiogram ("ECG") monitors, weighing scales, and / or heart rate monitors. In other examples, the medical fluid data transfer system 1000 may include fewer medical devices and / or medical devices integrated together (e.g., the blood pressure monitor 104 integrated with the home therapy machine 90).

[0180] In some embodiments, the personal mobile communication device 200a is configured to record, display, and / or input medical information or data into the patient medical record. 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 the medical device, the patient, and / or consumable items used by the medical device. For example, medical information includes prescription or programming information used by the medical device to administer treatment. Medical information includes sensed data such as fluid pressure, flow rate, conductivity, concentration, temperature, and patient data. As provided herein, patient data (e.g., vital sign data) includes sensed physiological information of the patient such as the patient's blood pressure, weight, and heart rate. Medical information may also include subjective information such as information about the patient's mood (e.g., bored, tired, satisfied, excited, etc.). Medical information may be displayable on the screen of the medical device, provided by a physical dial or display of the medical device, or printed on an attached sign or on the medical device. Therefore, medical device data or medical information includes medical device settings, medical device readings, and / or patient readings.

[0181] Medical information also refers to information contained on identifiers attached to patients or therapeutic consumable items. Specifically, medical information may include information conveyed by patient identifiers provided on a patient's wristband to identify the patient. Medical information also includes information about consumable items, which may identify characteristics of the consumable item, such as the consumable item type, consumable item model, and / or the level of glucose in a renal failure therapy solution supply bag.

[0182] Treatment data or treatment information refers to data generated and / or transmitted by the home therapy machine 90 in Figure 1-10. Treatment information may include the volume of fluid injected, the amount of ultrafiltration UF removed from the patient, and / or treatment time. Treatment information may also include alarms, alerts, and / or diagnostic information generated by the home therapy machine 90. Generally, treatment information is transmitted from the home therapy machine 90 to the clinician server 200b. In some embodiments, treatment information may be recorded in a personal mobile communication device 200a. In these embodiments, treatment information is referred to as medical information and / or may be included / processed as medical information.

[0183] As shown in Figure 10, some of all of the medical devices 90, 104, and 106 may include an identifier 1012 configured to store a unique identification number. The identifier 1012 may, for example, encode the assigned device number, serial number, hardware number, model number, and / or device type of each medical device 90, 104, and 106. For example, the identifier 1012b of the home therapy machine 90 may store the assigned device number. The personal mobile communication device 200a reads the identifier 1012b from the screen of the machine 90 to, for example, determine the medical device type for subsequent analysis and to identify medical information in recorded images. 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 device 106 is a weighing scale and / or indicate the model number of the weighing scale.

[0184] Identifier 1012 may include machine-readable markings such as barcodes or quick-response ("QR") codes. Identifier 1012 may also include human-readable text such as serial numbers, asset numbers, or hardware numbers. In some embodiments, identifier 1012, such as identifier 1012b shown for home therapy machine 90, may be printed on articles physically attached to the housings of the respective medical devices 90, 104, and 106. In addition, or alternatively, identifier 1012 may be displayed on the screens of some of all of the medical devices 90, 104, and 106. For example, a clinician may select a control interface and cause home therapy machine 90 to display a window with identifier 1012b on its screen. In other embodiments, identifier 1012 may be contained within a radio frequency ("RF") microchip such as an RFID chip or an NFC chip.

[0185] The exemplary medical devices 90, 104, and 106 may also include one or more control interfaces for providing control commands. For example, the home therapy machine 90 includes a control interface 1014. The control interface may include buttons, a control panel, or a touchscreen. The control interface may be configured to allow a user to navigate to a window or user interface on the screen of each medical device 90, 104, and 106. The control interface may also provide commands for operating or controlling each medical device 90, 104, and 106.

[0186] As illustrated in Figure 10, the exemplary fluid data transfer system 1000 includes a web portal 150 (similar to the respective devices discussed in relation to Figures 1-9), a system hub 120, and a clinician server 200b for communicating with a personal mobile communication device 200a. The web portal 150, system hub 120, and / or clinician server 200b transmit medical information from the patient's medical records (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 may provide the personal mobile communication device 200a with access to educational materials or real-time help sessions with a clinician. The exemplary 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 input into the patient's medical records.

[0187] The exemplary fluid data transfer system 1000 in Figure 10 also includes a connection server 118 which is communicatively coupled to the home therapy machine 90. As discussed above in relation to Figures 1-9, the connection server 118 provides bidirectional communication between the home therapy machine 90 and the clinician server 200b and / or clinician database 1010. The home therapy machine 90 may connect to the connection server 118 via the Internet.

[0188] In the illustrated example of Figure 10, the exemplary personal mobile communication device 200a includes a processor 1016 that communicates with a memory 1018 that stores instructions. At least some of the instructions define or specify an application 1002, which, 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 comprise digital and analog circuits structured as a microprocessor, an application-specific integrated circuit ("ASIC"), a controller, etc. The memory 1018 includes a volatile or non-volatile storage medium. Furthermore, the memory 1018 may include any solid or disk storage medium.

[0189] As will be discussed in more detail below, the features of application 1002 include displaying treatment progress information, controlling treatment programs initiated by the home therapy machine 90, recording medical information, displaying educational materials, and / or initiating a help session with a clinician. Application 1002 may be feature-rich or feature-sparse. Feature-rich applications are configured for smartphones and take advantage of the unique graphics, touchscreen, and processing power of the personal mobile communication device 200a. Feature-sparse applications are configured to run on cellular phones with relatively less sophisticated graphics and reduced processing power. Cellular phones may not have a touchscreen, or they may have a touchscreen with limited capabilities.

[0190] In some embodiments, the personal mobile communication device 200a may not include application 1002. Instead, the personal mobile communication device 200a may use a proprietary application 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.

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

[0192] In some cases, application 1002 on a personal mobile communication device 200a and / or application 1020 on a clinician server 200b are configured to convert or otherwise provide medical information to a clinician database 1010 on other devices within a medical fluid data transfer system 1000 that conforms to the Health Level 7 ("HL7") standard (e.g., medical standard). This conversion allows the medical information to be stored in HL7 format, regardless of the format in which it is input to the personal mobile communication device 200a. Applications 1002 and / or 1020 may act as network conduits for seamlessly propagating relevant medical information from medical devices to patient medical records when gaps in network or device connectivity exist.

[0193] Figure 11 shows a schematic diagram illustrating an operational module of application 1020 in the clinician server 200b of Figure 10, according to one embodiment of the present disclosure. Application 1020 may include a registration module 1102 configured to register a home therapy machine 90 and / or personal mobile communication device 200a with a specific patient and / or patient medical record stored in the clinician database 1010. As will be described in more detail in relation to Figure 12, registration may include determining the type of personal mobile communication device 200a in order to format subsequent communications.

[0194] Application 1020 may also include a data acquisition module 1104 configured to receive treatment and / or medical information from a registered home therapy machine 90 and / or a personal mobile communication device 200a. In addition, Application 1020 may include a data access module 1106 to transmit or otherwise provide access to medical information stored in one or more patient records associated with a patient. Application 1020 may further include an education module 1108 configured to provide patients with access to educational materials or help documents regarding the operation of their treatment and / or home therapy machine 90. Furthermore, Application 1020 may include a treatment control module 1110 that allows a patient (or clinician) to change (or modify) the treatment program performed by the home therapy machine 90. In addition, Application 1020 may include an auxiliary module 1112 that creates a real-time communication session between the personal mobile communication device 200a and the clinician device 152.

[0195] Each of the exemplary modules 1102–1112 is configured to improve patient engagement with medical fluid delivery therapy, thereby improving patient compliance with prescribed treatment. While modules 1102–1112 are shown, it should be understood that exemplary application 1020 may include fewer or additional modules. For example, in some embodiments, the educational module 1108 and the auxiliary module 1112 may be omitted. The following sections provide further descriptions of each of modules 1102–1112.

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

[0197] (A. Registration Module Embodiment) The exemplary registration module 1102 is configured to register a personal mobile communication device 200a and / or home therapy machine 90 with the clinician server 200b and / or with the patient's medical records stored in the database 1010. The exemplary registration module 1102 is configured to provide different types of registrations, which are used by the data access module 1106 to determine how the information should be presented to the patient based on the type of device being registered. In addition, the data acquisition module 1104 determines how the treatment and / or medical information should be acquired based on the registration information.

[0198] The registration module 1102 is configured to store registration information in a registration file stored in the clinician database 1010. The registration file may contain, for each patient or patient activation code ("PAC"), information indicating a registered personal mobile communication device 200a, information indicating a registered home therapy machine 90, and / or instructions regarding whether 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.

[0199] In several embodiments, different registration scenarios exist. For example, a patient may register a personal mobile communication device 200a and a home therapy machine 90 at the same time by downloading application 1002. In this scenario, the registration module 1102 records that the patient has installed application 1002 on the personal mobile communication device 200a and registered the home therapy machine 90 (separately or through application 1002). Based on this registration, the data acquisition module 1104 determines that application 1002 installed on the registered personal mobile communication device 200a should guide or otherwise prompt the patient to obtain medical information. In addition, the data acquisition module 1104 determines that the treatment information should be received from the home therapy machine 90 rather than via the personal mobile communication device 200a. Accordingly, the data acquisition module 1104 may send a message to application 1002 to disable the user interface for obtaining treatment information from the home therapy machine 90 (however, it may still enable the user interface for manual replacement if manual replacement is prescribed for the patient). If the home therapy device 90 is not registered, the data acquisition module 1104 causes the application 1002 to display a user interface in order to obtain treatment information from the home therapy device 90. Through registration, the data access module 1106 determines that the information should be displayed through the application 1002 and, accordingly, uses APIs and / or other data reading components that are suitable for or configured for the application 1002.

[0200] If the patient has registered without downloading and / or installing application 1002, the data acquisition module 1104 determines whether data acquisition should be prompted or guided. For example, the data acquisition module 1104 may (if the home therapy machine 90 is not registered) send a text message and / or email to the registered personal mobile communication device 200a to prompt the patient regarding certain medical and / or treatment information. The information in the message specifies the data required from the patient. This remote guidance can be used for a personal mobile communication device 200a with fewer features, but it can also be used for a smartphone where the patient does not wish to download or install application 1002 on a feature-rich device.

[0201] The data access module 1106 may also be configured to display information from the patient's medical records differently if application 1002 is not installed. For example, instead of transmitting data to plug into a user interface rich in clearly defined features, the data access module 1106 may render the data in photographs for viewing, which are transmitted via text to the personal mobile communication device 200a. In addition, or alternatively, the data access module 1106 may transmit the stored medical record information as text to the personal mobile communication device 200a. Thus, even if application 1002 is not installed, application 1020 on the clinician server 200b is configured to provide the patient with access to the data using a specific application on the personal mobile communication device 200a.

[0202] Figure 12 shows a schematic diagram illustrating communication between the home therapy machine 90 of Figures 10 and 11, a personal mobile communication device 200a, and a clinician server 200b according to an exemplary embodiment of the present disclosure. First, the home therapy machine 90 is registered with the clinician server 200b via the registration module 1102 of Figure 11. Otherwise, the clinician server 200b would not have information about patient record data from the home therapy machine 90 to be stored. In some embodiments, the home therapy machine 90 is pre-programmed with destination address information relating to the connection server 118, the system hub 120, and / or the clinician server 200b. The destination addresses may include Internet Protocol ("IP") addresses and / or Hypertext Transfer (or Transport) Protocol ("HTTP") addresses.

[0203] During setup, the patient (or clinician) enters a patient activation code ("PAC") into the home therapy machine 90. The PAC is originally generated and stored in the clinician server 200b and provided to the patient when the patient receives the home therapy machine 90. The PAC may include a patient identifier or other codes unique to the patient. The registration module 1102 in the clinician server 200b stores the generated PAC in one or more patient records and / or registration files associated with the patient. After the PAC is entered, the home therapy machine 90 generates and transmits a message 1202 containing the PAC. The message may also include the hardware identifier of the home therapy machine 90 and / or the IP address assigned to the home therapy machine 90. The home therapy machine 90 transmits the message 1202 to a pre-programmed address, in this case, the connection server 118. The exemplary 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 in the clinician server 200b registers the home therapy device 90 with the patient using PAC. Registration includes, for example, associating the identifier of the home therapy device 90 with the patient's medical record. Registration may also include the clinician server 200b storing the IP address of the home therapy device 90 and enabling messages to be transmitted to the home therapy device 90. After registration, the data retrieval module 1104 of the clinician server 200b stores the treatment information received from the home therapy device 90 in one or more medical records associated with the patient.

[0204] An exemplary personal mobile communication device 200a is also configured to register with the clinician server 200b via the registration module 1102. To register, the personal mobile communication device 200a may download or otherwise receive the application 1002 via one or more messages 1204 from the clinician server 200b (or a third-party application store). In one embodiment, during registration of the home therapy machine 90, the patient (or clinician) may provide a telephone number for the personal mobile communication device 200a. The registration module 1102 uses the telephone number and transmits 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 download to the personal mobile communication device 200a. In other instances, the message 1204 may include an attachment that, when executed, installs the application 1002 on the personal mobile communication device 200a. Instead of providing a telephone number, the patient may instead provide an email address during registration of the home therapy machine 90. Therefore, message 1204 includes an email message containing a file or hyperlink for installing application 1002 on a personal mobile communication device 200a.

[0205] In another embodiment, message 1204 may allow the patient to register in two different ways, depending on the capabilities and / or personal preferences of their personal mobile communication device 200a. Message 1204 includes text prompting the patient to respond to that text if the patient wishes to register their personal mobile communication device 200a as a less feature-rich device. A reply to message 1204 is provided via text message 1206, which is routed to the registration module 1102. The registration module 1102 then registers the personal mobile communication device 200a with instructions that application 1002 is not installed. In some cases, message 1204 may also include text or a hyperlink prompting the patient to select a hyperlink, if desired, or otherwise obtain application 1002. Message 1204 may also provide a prompt or option to select a device type, such as an Apple® device or an Android® device. During the registration process, the registration module 1102 registers the personal mobile communication device 200a based on information provided by the patient and / or information read from the personal mobile communication device 200a.

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

[0207] In some cases, application 1002 may consist of a destination address in the web portal 150, which is used to transmit messages. In other cases, message 1206 may be provided to an API in the web portal 150 to register application 1002 in the clinician server 200b. In yet another case, application 1002 transmits message 1206 to the web portal 150 as one or more text messages or email messages (the web portal 150 is assigned a phone number, IP address, email address, or other address). Exemplary registration module 1102 uses the PAC in message 1206 to register the personal mobile communication device 200a in the medical records and / or registration files stored in the database 1010. At this point, both the home therapy machine 90 and the personal mobile communication device 200a are registered with the same patient in the clinician server 200b.

[0208] As mentioned 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 text message or through a web browser. Thus, the registration module 1102 of the clinician server 200b may transmit a text message to the personal mobile communication device 200a with a hyperlink to a database or web page for completing registration. Alternatively, the text message may include a prompt for the patient to respond in their PAC. Providing the PAC through any of these registration processes enables the registration module 1102 to associate the personal mobile communication device 200a (e.g., a telephone number, hardware address, or IP address) with the appropriate patient medical record and / or registration file.

[0209] (B. Data Acquisition Module Embodiment) Figure 12 also illustrates data communication between the home therapy machine 90, a personal mobile communication device 200a, and a clinician server 200b. During operation, the home therapy machine 90 generates treatment information and status information (e.g., medical information). As discussed above in relation to Figures 1-9, treatment information includes the volume of fluid injected, the amount of ultrafiltration ("UF") removed from the patient, and / or treatment time. Status information includes alarms, alerts, or diagnostic information. Before or after treatment, the home therapy machine 90 generates one or more messages 1208 with medical information, which are transmitted to the connection server 118. Subsequently, the connection server 118 routes the messages 1208 to the system hub 120, which routes the messages 1208 to the data acquisition module 1104 of the clinician server 200b. After reception, the data acquisition module 1104 stores the medical information in a designated section of the patient's medical record (e.g., patient medical record 1302 in Figure 13). Message 1208 may contain an identifier or address of the home therapy machine 90, which is used by the data retrieval module 1104 to find the appropriate medical record in the database 1010.

[0210] The exemplary home therapy machine 90 may be configured to encode, label, or otherwise identify transmitted medical information using metadata or other data identification techniques. Encoding or labeling allows the data acquisition module 1104 (or interface in server 200b) to determine the context of the medical information for writing it to the appropriate field in the patient record. In addition, or alternatively, the encoding or labeling may be stored in the record, which can then be used to retrieve and display the medical information.

[0211] Figure 12 illustrates how a personal mobile communication device 200a transmits medical information or medical data to a clinician server 200b. As will be described in more detail below, the personal mobile communication device 200a is configured to retrieve medical information from medical devices, including devices 90, 104, and 106. Retrieving medical information may include receiving information manually entered 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 retrieved medical information is packaged into one or more messages 1210 and transmitted by the personal mobile communication device 200a to the web portal 150. The messages 1210 may be text messages, email messages, or web-based messages (e.g., HTTP messages, Extended Markup Language ("XML") messages, Java Script Object Notation ("JSON") payloads, etc.). In some embodiments, the personal mobile communication device 200a may format the retrieved medical information into one or more data fields prior to transmission. Generally, medical information obtained by the personal mobile communication device 200a is less structured than medical information generated by the home therapy machine 90. Therefore, the data acquisition module of the personal mobile communication device 200a, and / or the clinician server 200b, performs processing on at least some of the medical information to provide appropriate context or structure for inclusion in the patient medical record. Examples of the processing performed are described in more detail below.

[0212] Figure 13 illustrates an exemplary patient data structure 1300 stored on the clinician database 1010 of Figure 10, according to an exemplary embodiment of the present disclosure. The patient data structure 1300 includes separate patient records for different patients. In the illustrated example, the data structure 1300 includes a patient medical record 1302 for a patient associated with identifier "DCM31913" and a patient medical record 1304 for a patient associated with identifier "GAM41215". The data structure 1300 may include additional patient medical records.

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

[0214] Furthermore, as shown in Figure 13, medical records 1302 and 1304 include fields relating to treatment and medical information. The data acquisition module 1104 stores treatment information received from each home therapy machine 90 in records 1302 and 1304. In addition, the data acquisition module 1104 stores medical information received from each personal mobile communication device 200a in records 1302 and 1304. In some embodiments, the data fields are further divided into individual fields relating to data types. For example, records 1302 and 1304 may include treatment information fields relating to the volume of fluid injected, the amount of ultrafiltration ("UF") removed from the patient, and / or treatment time. Records 1302 and 1304 may also include data fields relating to alerts or alarms generated during treatment, and / or alarms or alerts determined by the clinician server 200b based on the treatment and / or medical information. Records 1302 and 1304 may further include medical information regarding the patient's weight and / or blood pressure recorded before, during, and / or after treatment.

[0215] Treatment and / or medical devices may be organized by treatment, date / time of occurrence, and / or date / time of receipt. In some embodiments, medical records 1302 and 1304 may store communications from the patient. Communications may include photographs or videos recorded by a personal mobile communication device 200a related to the treatment, or questions about the treatment. Communications may also include text messages, emails, etc., related to treatment assistance sent from the personal mobile communication device 200a. Furthermore, communications may include information related to requests from the personal mobile communication device 200a and / or the clinician device 152 to change or modify the treatment. In general, medical records 1302 and 1304 are configured to store information for improving the patient's involvement in the treatment, in addition to documenting the outcome of the treatment and information related to the patient's involvement with the clinician server 200b regarding the treatment.

[0216] The data received by the exemplary data acquisition module 1104 varies depending on the source. For example, treatment information received from the home therapy machine 90 is generally structured. In other words, the home therapy machine 90 is configured to transmit treatment information that is formatted for direct input into one or more data fields of the patient's medical record. In some embodiments, the home therapy machine 90 formats the message for transmission through the API of the data acquisition module 1104 (or otherwise accesses one or more APIs) for inputting the treatment information into the appropriate data fields. In contrast, medical information recorded by the patient's personal mobile communication device 200a may not be structured initially for inclusion in the patient's medical record. Different techniques may be used by the data acquisition module 1104 of the application 1002 of the personal mobile communication device 200a and / or the clinician server 200b to process and / or format the medical information for input into the medical record, as will be described in more detail below.

[0217] (1. Implementation of manual entry of medical information into the application) To receive structured information, an exemplary application 1002 of the personal mobile communication device 200a is configured in some embodiments to display prompts indicating medical information required for the patient to enter into a patient medical record. The exemplary application 1002 may include routines or algorithms that define fields to be displayed to prompt for medical information from the patient. In some embodiments, the fields or screens on which the fields are displayed are arranged and / or ordered in relation to medical fluid delivery therapy. The display of the fields informs the patient about medical information required for the patient record.

[0218] Figures 14 and 15 show schematic diagrams illustrating the user interface of application 1002, which enables the patient to input medical information for transmission to the data acquisition module 1104. Specifically, user interface 1400 in Figure 14 prompts the patient regarding blood pressure information, while user interface 1500 in Figure 15 prompts the patient regarding medical fluid delivery information (e.g., treatment information). It should be understood that application 1002 of the personal mobile communication device 200a may display other user interface screens that enable the patient to manually input medical information. For example, application 1002 may display user interface screens regarding blood glucose levels, patient body temperature, patient weight, etc.

[0219] In some embodiments, the patient may obtain other medical information wirelessly or record certain medical information via images, but may manually input some of the medical information through the user interface 1400 or 1500. In these configurations, application 1002 may be configured to allow the patient to select an information input source. The patient may manually input medical information after selecting a manual source from a menu of available data input methods, or by default.

[0220] After receiving medical information manually entered by the patient, the exemplary application 1002 transmits the medical information to the data acquisition module 1104 for inclusion in the patient's medical record. The application 1002 and user interfaces 1400 and 1500 are configured such that data fields for receiving medical information are aligned with data fields in one or more medical records. In some examples, the data fields may correspond to one or more APIs in the data acquisition module 1104 for writing the medical information directly to the designed data fields in the patient's medical record. The application's user interfaces 1400 and 1500 therefore prompt the patient regarding the medical information in a structured manner such that identification or formatting of the medical information is not required or is not necessary.

[0221] In some embodiments, application 1002 may be configured to display user interfaces 1400 and 1500 at designed times. For example, application 1002 may include a calendar containing the times / days in which treatment is scheduled. At a designed time before treatment (e.g., 5 minutes, 15 minutes, 30 minutes, etc.), exemplary application 1002 is configured to display user interface 1400 on a personal mobile communication device 200a and prompt the patient regarding blood pressure medical information. The prompt informs the patient that blood pressure measurement is required before treatment begins. The patient then uses the blood pressure monitor 104 to perform a blood pressure measurement. The patient then enters the measurement value into user interface 1400 before treatment begins.

[0222] In the illustrated embodiment, the user interface 1400 includes a systolic blood pressure data field 1402, a diastolic blood pressure data field 1404, and a pulse rate data field 1406. The patient may select each of the data fields 1402, 1404, or 1406 and have the application 1002 display text input features for entering values. The user interface 1400 includes a field 1408 that allows the patient to specify whether the blood pressure measurement was performed in a standing or sitting position. Furthermore, the user interface 1400 includes a data field 1410 that allows the user to specify the date / time the blood pressure measurement was performed.

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

[0224] The user interface 1500 in Figure 15 is configured to be displayed by application 1002 when a patient is scheduled to undergo manual replacement therapy and / or when the home therapy machine 90 is not registered with the clinician server 200b. Manual replacement therapy requires the patient to connect a container of dialysis fluid to their abdominal cavity for a duration of residence before allowing the used dialysis fluid to be drained without the assistance of the machine. With regard to manual therapy, the patient is required to enter their manual replacement medical information so that their records can reflect accurate treatment information.

[0225] The exemplary application 1002 may also be configured to display the user interface 1500 when the patient has not registered the home therapy device 90. During registration, the registration module 1102 may transmit a message to application 1002 indicating whether the home therapy device 90 is registered. If the home therapy device is not registered, application 1002 may be configured to display the user interface 1500 and / or other user interfaces to obtain treatment information that may normally be transmitted by the home therapy device 90.

[0226] In the illustrated example, the user interface 1500 includes a progression through treatment, including a solution stage, a discharge stage, a filling stage, a UF or retention stage, and an explanation stage. The application 1002 may display separate user interfaces for each stage, prompting the patient to enter corresponding or requested treatment information. The exemplary user interface 1500 corresponds to the UF stage, as indicated by the highlighted frame 1502. The user interface 1500 includes a discharge volume field 1504, a UF field 1506, and a filling volume field 1508. In the illustrated example, the user interface 1500 prompts the patient to enter the discharge volume into the data field 1504 during the discharge stage and the filling volume into the data field 1508 during the filling stage. The user interface 1500 may calculate a UF value with respect to the UF data field 1506, or prompt the patient for a certain value.

[0227] Instead of displaying user interfaces 1400 and 1500 at the designed time, application 1002 may instead display an alarm on the personal mobile communication device 200a. The alarm may identify the required medical information or include a link to either user interface 1400 or 1500. The alarm may include a pop-up window displayed by the personal mobile communication device 200a. The alarm may also include an icon displayed adjacent to the icon for application 1002 on the home screen of the personal mobile communication device 200a. In other embodiments, application 1002 may not notify the patient of the required medical information. Instead, application 1002 may allow the patient to navigate to a desired user interface for entering medical device data and / or treatment information.

[0228] In some embodiments, application 1002 may identify at least some of the data fields of one or more user interfaces as being requested for input, with other data fields being optional for input. Application 1002 may outline the requested data fields or otherwise represent them graphically (e.g., display a red border around the systolic blood pressure data field 1402). Application 1002 may cause an alert message to be displayed by the personal mobile communication device 200a if the requested data fields are incomplete or not completed by a certain time. In some embodiments, application 1002 may prevent the patient from navigating to another user interface until all requested fields have been populated with data for the currently viewed user interface.

[0229] After medical information is entered by the patient into one or more of the interfaces 1400 and 1500, 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. Application 1002 is configured to transmit medical information after the patient has filled in a data field in the user interface or, otherwise, after pressing a submit button on the interface. In other cases, application 1002 may transmit medical information at a predetermined time, such as before or after treatment.

[0230] (2. Implementation of wireless input of medical information to an application) In some embodiments, the patient may choose to wirelessly input medical information into their personal mobile communication device 200a. The medical information may be received by the personal mobile communication device 200a via, for example, Bluetooth® connection, Zigbee® connection, Z-Wave® connection, wireless USB connection, wireless RF connection, NFC connection, infrared connection, or any other suitable wireless communication technology. In some cases, the patient may need to wirelessly pair the personal mobile communication device 200a with a medical device such as a blood pressure monitor 104 and / or measuring device 106. In other embodiments, the patient activates a connection application (e.g., an NFC application) to wirelessly read medical information from the medical device.

[0231] In one example, a patient may pair their personal mobile communication device 200a with a blood pressure monitor 104. To input blood pressure medical information into the user interface 1400 in Figure 14, the user selects, for example, the systolic blood pressure data field 1402. The selection of field 1402 prompts application 1002 to display a prompt asking the patient to select a data input method (e.g., manual, wireless, photograph, etc.). After selecting the wireless option, application 1002 displays a menu of available wireless connection options and / or a list of paired Bluetooth® devices. The patient selects the blood pressure monitor 104 from the list, causing it to display a menu of available medical information. The patient selects systolic blood pressure, causing it to populate the systolic blood pressure value in the systolic blood pressure data field 1402. In some embodiments, application 1002 is configured to read medical information from the blood pressure monitor 104 after the device has been selected by the patient. Application 1002 may use data labels or metadata to determine which fields 1402-1410 should be populated with medical information from the blood pressure monitor 104.

[0232] In some embodiments, application 1002 is configured to allow the patient to establish a permanent or semi-permanent connection with a medical device. During the setup operation, application 1002 prompts the patient to select a data field from the user interface 1400. After selection, 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 application 1002 to automatically read medical information from the blood pressure monitor 104 when new medical information becomes available. In other words, application 1002 is configured to wirelessly and automatically access a remote medical device, read some medical information, and populate one or more data fields. For example, after the patient has used the blood pressure monitor 104 to take a blood pressure measurement, the monitor 104 transmits a pin or status message to application 1002 indicating that new data is available. Alternatively, application 1002 may poll or otherwise pin the blood pressure monitor 104 to determine whether new data is available. Application 1002 then reads the new data into one or more of the data fields 1402-1410 and automatically populates the user interface 1400. Application 1002 then sends the medical information to the data acquisition module 1104 of the clinician server 200b, automatically updating the patient's medical record.

[0233] (3. Implementation of image input of medical information into the application) An exemplary application 1002 on a personal mobile communication device 200a is configured to allow a patient to input medical and / or treatment information by recording images of a medical device or the screen of a medical device. The personal mobile communication device 200a uses a camera 1004 to record one or more images. Application 1002 uses optical character recognition ("OCR") to extract text from the recorded images. The extracted text is entered into one or more data fields in the user interface of application 1002. The use of images can reduce data entry errors from patients or clinicians.

[0234] In some embodiments, application 1002 uses rules or data templates to identify text from images that may be selectable as relevant medical information for data fields. Otherwise, simply using OCR features would make all displayed text selectable. Thus, the patient would still need to copy and paste the text from the image into the data field. In comparison, rules or data templates can classify or identify text from images as fields, which allows for easy or automatic selection by the patient for input into data fields in the user interface.

[0235] The data templates or rules of application 1002 are configured to organize or otherwise decode text extracted from an image. Application 1002 determines or otherwise selects one or more data templates to establish context about the medical information, for example, based on the location of the medical information in the image and / or the labels / keywords contained within the medical information. To determine the data template, exemplary application 1002 may prompt the patient to specify the type of medical device on which the image was recorded. In addition, or alternatively, application 1002 allows the patient to select a medical device template. In yet another embodiment, the patient may first record an image of identifier 1012 (e.g., an identifier image), which is used by application 1002 to determine the type, model, etc., of the corresponding medical device. Application 1002 then selects a data template or rule corresponding to the type, model, screen, etc., of the medical device.

[0236] A data template defines or specifies a data field for certain medical information contained within an image. Generally, the image contains extracted text that includes medical information. In some cases, not all of the extracted medical information is required or necessary. Instead, only certain medical information within the recorded image is required for input into data fields in the user interface or patient medical record. Relevant medical information or related medical information refers to medical device data or medical information identified or selected for input into data fields in the user interface of application 1002, or more generally, for input into the patient's medical record.

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

[0238] The exemplary data processor 1602 may be configured to manage the acquisition of medical information from one or more images. Such management includes displaying one or more camera messages via a screen 1002, where the camera messages provide information that prompts a clinician or patient (e.g., an operator) to record a particular image. Alternatively, after a patient selects to input medical information into one or more data fields of an application 1002 using an image input method, the data processor 1602 may initiate an image processing mode. After selection of the image input method, the data processor 1602 is configured to obtain one or more images.

[0239] In some embodiments, the data processor 1602 causes a camera application to be opened on the personal mobile communication device 200a, enabling a patient to record one or more images. The patient may further select the recorded images to be processed or discarded. The selected images are analyzed to identify text (as medical information) for potential entry into data fields of one or more user interfaces of the application 1002. [[ID=]10]

[0240] In other embodiments, the data processor 1602 may guide the patient through one or more steps to acquire images. The data processor 1602 may execute a workflow or routine based on a data field selected by the patient. For example, the data processor 1602 may execute a blood pressure workflow to acquire images from a blood pressure monitor based on the patient selecting the systolic blood pressure data field 1402.

[0241] In one example, the data processor 1602 in Figure 16 is configured to display a camera message identifying the medical device to be recorded, the user interface window of the medical device, and / or an identifier on the medical device. The data processor 1602 may also display a navigation message specifying the user interface window of the medical device for imaging. Furthermore, the data processor 1602 may display a reminder message if an image is not recorded within a predetermined period (e.g., 5 minutes). The message may include text providing instructions and / or text identifying the intended target for imaging. The message may also include instructions on how to navigate to a user interface window of the medical device using the medical device's control interface. The message may further include graphical elements such as illustrative diagrams of the medical device, consumable items, identifier 1012, and / or user interface window from which the image should be recorded.

[0242] It should be understood that in some embodiments, the data processor 1602 does not display a message. Instead, the data processor 1602 responds to images recorded by the patient to determine relevant medical information. For example, upon receiving an indication that an image has been recorded, the data processor 1602 operates a workflow in which application 1002 prompts the clinician to identify the medical device on which the image was recorded. The prompt may include a pull-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 labels to determine the extracted medical information to be populated or written to a data field in the user interface or medical record.

[0243] To record images, exemplary data processor 1602 and image processor 1604 (more commonly, processor 1016) provide operations for application 1002 associated with camera 1004. The patient provides instructions to record images via camera user interface 1606 (e.g., a touchscreen or button on a personal mobile communication device 200a). The patient activates camera user interface 1606, for example, when the camera is focused on a medical device user interface window or identifier 1012. Data processor 1602 receives the instructions and commands camera 1004 to record images. Recorded images are transmitted from camera 1004 to image processor 1604. In addition, a copy of the image is displayed by data processor 1602 on the display interface 1022 of personal mobile communication device 200a.

[0244] In some embodiments, the data processor 1602 may display an afterimage image illustrating the image to be recorded on the display interface 1022. The afterimage image is provided on top of the stream of images provided by the camera 1004 in preview mode. The purpose of the afterimage image is to provide a clinician or patient with assistance in confirming that the image to be recorded contains the desired medical information and is recorded at an appropriate distance. For example, the data processor 1602 may display an afterimage image of a given identifier on a given medical device. The patient aligns the personal mobile communication device 200a so that the stream of images of identifier 1012a is aligned positionally with the afterimage image. The patient can then record the image of identifier 1012a. In some cases, the data processor 1602 uses image analysis to determine the difference between the afterimage image and the stream of images. The data processor 1602 may display instructions prompting the patient to move the personal mobile communication device 200a in a certain direction to reduce the determined difference. The data processor 1602 may determine when the difference falls below a certain threshold and indicate that the images are aligned. When the images are substantially aligned, the data processor 1602 may provide a graphical indication on the display interface 1022 that the images can be recorded, or the images may be recorded automatically without input from the patient.

[0245] The data processor 1602 may provide a prompt to the patient to accept the image. After receiving the acceptance instruction 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 instruction to delete the image via the camera user interface 1606. Until the image is deleted, the image processor 1604 performs analysis to identify text.

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

[0247] In addition to performing OCR to identify text, the image processor 1604 may also be configured to use image analysis to identify patients, medical devices, and / or consumable items. For example, the image processor 1604 may access a library of medical device images to identify medical devices in an image. In this example, the image processor 104 may use an image matching routine to determine a match. Such a comparison may be performed on behalf of a medical device having identifier 1012. The image processor 1604 may use a similar routine and / or algorithm to identify consumable item 1006.

[0248] An exemplary data processor 1602 is configured to decode identifier 1012 and determine the type of medical device of a consumable item. Decoding may include relating the position and thickness of lines and / or rectangles to relevant medical information. The coded lines and rectangles may correspond to a sequence of letters and / or numbers. For example, data processor 1602 may use the lines or rectangles of identifier 1012 to determine a device model number, medical device type, asset code, etc. The decoded identifier 1012 may provide relevant medical information for input into one or more data fields of the user interface of application 1002. In addition, or alternatively, the decoded identifier may be used by data processor 1602 to select a workflow for obtaining images from a medical device or consumable, and / or to determine a data template.

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

[0250] Figure 17 illustrates a schematic diagram of a data template 1700 according to an exemplary embodiment of the present disclosure. The exemplary data template 1700 is used by an image processor 1604 (e.g., application 1002) to identify extracted text as relevant medical information. Generally, the screen of a medical device displays medical information. Some of the information is relevant for inclusion in data fields of the user interface of application 1002. Other data is less relevant or may not be relevant at all. Furthermore, depending on the model of the medical device, the medical information may be located in different places or have different labels. The data template 1700 is configured to specify the location and name of relevant medical information relating to a particular home therapy machine 90.

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

[0252] The illustrative data template 1700 in Figure 17 includes device data (or text) fields 1702, 1704, 1706, and 1708, which define the location of certain medical information on a specific user interface window of a medical device. In some examples, the data template 1700 is graphical, thereby enabling image analysis to align fields 1702-1708 with extracted text in the image. In other examples, the data template 1700 includes a file (or other data structure) containing the coordinates or locations of each of the device data fields 1702-1708 relative to an origin. The image processor 1604 identifies the origin in the image with the extracted text and identifies the text for each of the data fields 1702-1708 based on a substantial match to the location in the data template 1700. In some examples, the image processor 1604 may scale the image to match the size or coordinate space of the data template 1700.

[0253] Some of the illustrated data fields 1702–1708 may include label text in addition to coordinates and / or location. For example, device data field 1702 includes the label text "Ultrafiltration window," while device data field 1704a includes the label text "UF volume." Image processor 1604 matches the label text to similar text extracted from the image. In some cases, matching between label texts is used exclusively to identify device data fields rather than using location or image analysis.

[0254] Matching between label texts, including label text related to unrelated device data fields, can be used to verify that an image is from the correct window or screen of a medical device. For example, the image processor 1604 may match the label text “ultrafiltration window” to the corresponding extracted text at a relatively similar location in the recorded image. The match verifies that the image was recorded from the ultrafiltration window of a renal failure therapy medical device. However, the extracted text is not relevant medical information relating to the patient’s medical record. If the label text does not match the extracted text, the image processor 1604 may display a message prompting the patient to record an image of the ultrafiltration window of the renal failure therapy medical device.

[0255] Identifier text associated with device data fields 1706 and 1708 may be used to verify that a recorded image is current or recorded within a predetermined period. For example, some windows on a medical device display the current date and time. This information may be extracted by the image processor 1604 and identified using device data fields 1706 and 1708. The image processor 1604 compares the extracted date / time to a date / time rule or limit associated with device data fields 1706-1708 to determine whether the recorded image is current. For example, the image processor 1604 may determine that if the date does not match, or if the time is not within a predetermined threshold for the current time on the personal mobile communication device 200a (e.g., 5 minutes, 15 minutes, 60 minutes, 3 hours, etc.), it is required to record another image.

[0256] The exemplary device data fields 1704a and 1704b in Figure 17 are used by application 1002 to identify relevant medical information. In some cases, application 1002 may display flags or metadata indicating that device data fields 1704a and 1704b are related to selected data fields in a user interface (e.g., user interface 1400 or 1500). In comparison, device data fields 1702, 1706, and 1708 may contain flags or metadata indicating that the corresponding extracted data is not relevant. In the example illustrated in Figure 17, image processor 1604 uses the labeling text of data field 1704a to find the corresponding extracted text in the image. Image processor 1604 then uses the positional relationship between device data fields 1704a and 1704b, or between text value markers, to identify the extracted medical information from the image corresponding to the numerical value of the critical filtration volume. The image processor 1604 copies the extracted medical information related to field 1704b from the image to input, for example, into the systolic blood pressure data field 1402 in Figure 14.

[0257] As discussed above in relation to Figure 17, the data processor 1602 in Figure 16 may use known positional relationships of text and text markers in the image to determine extracted text corresponding to relevant medical information. In some embodiments, the data processor 1602 selects a data template based on an indication of the model or type of medical device and / or consumable item. The indication may be determined from a previous image of identifier 1012, received from the patient via the camera user interface 1606, and / or specified through the selection of data fields in the user interface relating to application 1002 into which medical information should be entered. In other examples, the data processor 1602 compares a data template in database 1608 with the image accompanied by the extracted text to find a match. In these other examples, the data processor 1602 uses the position of text markers and the text between the image and the data template to determine a match.

[0258] The exemplary data processor 1602 is configured to identify relevant medical information and then write or otherwise populate the relevant medical information into one or more data fields in the user interface of application 1002. In some embodiments, the data processor 1602 is configured to automatically populate data fields in the user interface of application 1002 using a data template. To automatically populate medical information, the data processor 1602 compares the text, labels, and / or metadata associated with the fields in the data template with the text, labels, metadata, and / or other data field information in one or more user interfaces of application 1002. If at least some of the text, labels, and / or metadata match, the data processor 1602 identifies a text (e.g., a number) corresponding to the matching field in the data template. The identified text is written to the corresponding matching data field in the user interface of application 1002.

[0259] In other embodiments, the data processor 1602 is configured to select one or more fields of a data template and prompt the patient to populate one or more data fields of the user interface of application 1002 with data. Figure 18 shows a schematic diagram illustrating a patient populating data fields 1402-1406 of user interface 1400 according to an exemplary embodiment of the present disclosure. In the illustrated example, user interface 1400 is opened on a personal mobile communication device 200a. To populate the data fields 1402-1406 with medical information, the patient selects each of the data fields sequentially or together. With respect to each selection, application 1002 displays a prompt asking the patient how the data should be populated. After the patient has selected the photo input method, application 1002 opens a camera application, allowing the patient to use the personal mobile communication device 200a to record an image 1800 of the screen of the blood pressure monitor 104. In some embodiments, application 1002 may display text or graphics to assist the patient in obtaining the image, as described above.

[0260] After the image 1800 is recorded, the application 1002 performs an OCR operation to extract text. The application 1002 then determines a data template 1801 corresponding to the extracted text. In some embodiments, the application 1002 matches the location of text and / or labels in the image to the text and / or label locations in the data template to find a matching data template. In other examples, the patient may specify the instructions of the blood pressure monitor 104, which enables the application 1002 to find the corresponding data template 1801. In still other examples, the application 1002 may 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 a 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. This process includes the application 1002 identifying groups or fields of similar text. In some cases, the application 1002 may identify groups or fields of similar text based on the spacing between characters and / or words.

[0261] In the illustrated example in Figure 18, application 1002 provides fields 1802, 1804a, 1804b, 1806, 1808, and 1810 relating to different sets of text. The patient selects the field in which data should be populated into a selected data field in the user interface 1400. For example, to populate the systolic blood pressure data field 1402, the patient selects field 1804a. The patient's selection causes application 1002 to copy at least some of the data from field 1804a into data field 1402. Data field 1402 may include a rule specifying that only numerical integers can be accepted. Application 1002 reads the text relating to the numerical integer (i.e., "145") from the selected field 1804a. Application 1002 then populates the identified numerical integer into the systolic blood pressure data field 1402. The patient may use image 1800 to continue with respect to other fields 1404-1410 of the user interface 1400. In each case, the patient may choose to input data manually, wirelessly, or via images. If a second image is required (e.g., prompted by application 1002 or determined by the patient), application 1002 allows the patient to record and view multiple images. Application 1002 applies an appropriate data template to each of the recorded images. Application 1002 thus allows the patient to input information into the user interface 1400 using one or more recorded images, as if the patient were manually entering values.

[0262] In some embodiments, application 1002, more specifically data processor 1602, performs checks on user-selected extracted data to ensure that the values ​​are within a predetermined range and / or of a defined type. Application 1002 may perform similar checks on data manually entered by the patient or data received wirelessly from a medical device. Each data template and / or data field in the user interface may include metadata or rules for a particular field that provide a threshold or acceptable range for values. For example, metadata or rules for a weight data field may specify that a predetermined acceptable range for values ​​is 20 kg to 200 kg. For values ​​outside the predetermined range, application 1002 may display an error on the display interface 1022, or prompt the patient to record another image or correct the value.

[0263] Figure 19 illustrates a flowchart of an exemplary procedure 1900 for inputting medical information from images using application 1002 of a personal mobile communication device 200a, according to an exemplary embodiment of the present disclosure. While procedure 1900 is described with reference to the flowchart illustrated in Figure 19, it should be understood that many other ways of performing the steps associated with procedure 1900 may also be used. For example, the order of many blocks may be changed, some blocks may be combined with others, and many of the blocks described may be optional. In addition, exemplary procedure 1900 may include optional blocks for prompting the patient to record images of the medical device screen and / or identifier 1012.

[0264] Exemplary procedure 1900, in one embodiment, is initiated when application 1002 is invoked on a personal mobile communication device 200a and operates using processor 1016 to establish a wired and / or wireless connection with clinician server 200b (block 1902). Establishing the connection may include transmitting and / or receiving one or more messages 1903, one or more messages providing, for example, a device address, patient identifier, device identifier, network address, and / or protocol information for accessing and / or writing to the patient's medical records. After opening application 1002, the patient navigates a user interface (e.g., user interface 1400 or 1500 in Figures 14 and 15) to enter medical information or accesses it otherwise (block 1904).

[0265] Prior to block 1906, the patient uses application 1002 to select data fields and choose that medical information should be provided via photo input. In block 1906, the personal mobile communication device 200a records images 1907 of medical devices, consumables, the patient, etc. The images may include identifiers and / or screens of medical devices. The personal mobile communication device 200a then determines or identifies text in the recorded images (block 1908). For example, the personal mobile communication device 200a may perform an OCR routine on the images. In cases where the images include barcodes and / or QR codes, the personal mobile communication device 200a decodes the barcodes and / or QR codes. The captured or coded data is converted into text or U.S. Standard Code for Information Interchange ("ASCII") characters. In some embodiments, the personal mobile communication device 200a may also determine data fields relating to the identified text (block 1910). The data fields may be determined, for example, using a data template. As described above in relation to Figures 17 and 18, a data template may specify the location of certain text and / or the marker of certain text used to operationally place a data field over identified text in a recorded image. In some cases, the data field and / or data template may be selected by the patient and / or determined from the medical device identifier 1012. Alternatively, instead of using a template, procedure 1900 may instead provide instructions that a recently recorded image has relevant medical information for extraction, selection, and / or transfer.

[0266] In one embodiment, the exemplary procedure 1900 continues by determining whether there are additional images to be recorded (decision block 1912). In one example, procedure 1900 may access a list of images that are required to be recorded for a prescribed therapy or treatment. Procedure 1900 may guide the patient through a sequence to acquire all required images via a personal mobile communication device 200a, or provide prompts to acquire images containing medical information that is determined to be required or missing. In other examples, the patient may determine the required images. If additional images should be recorded, procedure 1900 returns to block 1906.

[0267] If no additional images are needed, as determined in decision block 1912, the patient initiates the process of inputting relevant medical information into the data fields of the user interface. The process in the illustrated embodiment includes enabling the patient to select an image into which relevant medical information should be transferred. Image selection causes the personal mobile communication device 200a to display the image on the display interface 1022 (block 1914). It should be understood that the selected image includes identified text and optionally, data fields. The patient may also specify the data fields (or locations within data fields) of the user interface into which the data should be input.

[0268] The personal mobile communication device 200a receives relevant medical information and / or a selection of data fields with relevant medical information for input into the designed data fields of the user interface of application 1002. The selection may be performed by the patient pressing an area on the touchscreen 1002 of the personal mobile communication device 200a corresponding to the medical information to be input. In one embodiment, the selection of relevant medical information and / or fields causes the personal mobile communication device 200a to automatically input at least a portion of the selected text (block 1916).

[0269] After the selected text has been entered, the personal mobile communication device 200a determines whether additional relevant medical information should be entered based on the selection of additional data fields in the user interface (decision block 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 to enter into data fields. If additional relevant medical information exists as determined in decision block 1918, procedure 1900 returns to blocks 1914-1916, and the patient specifies the images and / or relevant medical information for data field entry. If no additional relevant medical information exists for entry as determined in decision block 1918, exemplary procedure 1900 terminates.

[0270] (4. Image / Text Attachment Application Embodiment) In some embodiments, the exemplary application 1002 and clinician server 200b are configured to allow patients to provide images or text as attachments or addendums to their medical records. In the above section, application 1002 provides data fields in the user interface as prompts for desired information. However, in some cases, the patient or clinician may wish to provide additional information. In addition, or alternatively, one or more user interfaces of application 1002 may include data fields for free text input, prompts for the patient to enter text (e.g., "How are you feeling today?"), or features to allow a photograph or image to be incorporated as part of the record. For example, user interface 1400 may include a photograph icon adjacent to a prompt for an image of a fluid connection to the patient's abdomen, which, when selected, opens a camera application and allows the patient to attach the image for transmission along with medical information. The image may be stored in a designed field in the appropriate patient medical record.

[0271] An exemplary application 1002 on a personal mobile communication device 200a is configured to accept images and / or text provided by the patient. In one embodiment, application 1002 is configured to allow the patient to choose between text or photo input. If the patient chooses text input, application 1002 displays a text box. The patient enters information into the text box, which is stored by application 1002. Application 1002 may then transmit the information in one or more messages to the clinician server 200b. Application 1020 on the clinician server 200b determines the appropriate patient medical record in the database 1010 and finds a “note” or free text field. Application 1020 stores the text provided by the patient in the field. In some cases, application 1020 may also include a time / date stamp along with the entered text. This information provides the clinician with additional information from the patient, including feedback on treatment.

[0272] Figure 20 shows an example of a user interface 2000 displayable by an application 1002 on a personal mobile communication device 200a, enabling a patient to provide recorded images, according to an exemplary embodiment of the present disclosure. The exemplary user interface 2000 includes an image title field 2002, which may be editable by the patient. The user interface 2000 also includes one or more recorded images 2004 or a preview of recorded images. The application 1002 is configured to enable the patient to browse a gallery folder of recorded images and select an image to be transmitted. Date fields 2006 and time fields 2008 provide information in the user interface 2000 indicating the date / time the displayed image was recorded. The patient may select a “trash” button to discard an image 2004 or an “upload” button to transmit an image 2004 from the application 1002 to the clinician server 200b. The exemplary photo capture feature of the application 1002 enables the patient to document fluid line connectivity with the home therapy machine 90 or physiological conditions related to the treatment. Application 1020 on the clinician server 200b is configured to attach the received image 2004 to the patient's medical record or to link it to it in a different way.

[0273] (5. Manual / wireless / image input embodiments of medical information via text) In some embodiments, the personal mobile communication device 200a in Figure 10-12 may not be capable of installing or running application 1002, or the patient may decide not to install application 1002. However, the clinician server 200b still registers the personal mobile communication device 200a during the registration process. Instead of receiving medical information via application 1002, the data acquisition module 1104 of the clinician server 200b determines that a routine or algorithm should be executed to prompt the patient for medical information via the personal mobile communication device 200a or to acquire it otherwise. The exemplary data acquisition module 1104 may determine that the personal mobile communication device 200a is registered but application 1002 is not installed by reading the patient's registration file and / or medical records.

[0274] In some embodiments, the data acquisition module 1104 is configured to acquire medical information from a patient through one or more text messages. For example, at a designed time corresponding to the time of 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 initiate a sequence or routine for acquiring medical information. In yet another case, the patient may send a text message to the data acquisition module with medical information and / or images without a prompt message.

[0275] The exemplary data acquisition module 1104 in Figure 11 is configured to format or otherwise structure the received information for input into one or more data fields of the patient's medical record. Generally, medical information received from text messages is unstructured. In other words, text messages do not provide a clear correlation or reference to a designed field in the patient's medical record. Instead, the data acquisition module 1104 is configured to determine the appropriate field for the medical information received within the text message.

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

[0277] In these embodiments, the data acquisition module 1104 may be configured to send a follow-up text to the patient if the text from the received text message cannot be properly placed in the data field. For example, the data acquisition module 1104 may receive a message with the text “Blood pressure 145”. Based on the matching text, the data acquisition module 1104 determines that the message may correspond to a “systolic” or “diastolic” blood pressure data field. Accordingly, the data acquisition module 1104 transmits a message to the personal mobile communication device 200a with text asking the patient whether the value is “systolic” or “diastolic”.

[0278] In another embodiment, the data acquisition module 1104 prompts the patient through a sequence of messages (which may be defined by a routine or algorithm) to provide certain medical information. The order of the sequence is known or defined and corresponds to data fields in the medical record. Thus, the data acquisition module 1104 automatically determines that a response to a prompt corresponds to a data field in the medical record related to the prompt. For example, the data acquisition module 1104 transmits a text message prompting the patient about “systolic blood pressure measurement.” The data acquisition module 1104 determines that the response to the text contains a value related to “systolic blood pressure measurement.” The data acquisition module 1104 may analyze the received message to identify the numerical value from other text and / or to 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, based on the sequence of messages, a subsequent message to be sent to the personal mobile communication device 200a.

[0279] Instead of receiving messages with text, the data acquisition module 1104 may also receive messages with photo attachments. Similar to the process described above in relation to Figure 16-19, the data acquisition module 1104 is configured to process images, extract text, and identify relevant medical device data relating to one or more data fields of a medical record. Furthermore, while the above disclosure describes the use of text messages, the data acquisition module 1104 may, in addition or alternatively, receive medical information and / or photos via other communication media such as email, instant or web-based messaging, or social media posts.

[0280] Figure 21 shows a schematic diagram of a patient medical template 2100 according to an exemplary embodiment of the present disclosure, which may be used by a data acquisition module 1104 of a clinician server 200b to populate data fields in the patient's medical record. The fields of the template 2100 may correspond to or otherwise link to or reference data fields in the patient's medical record. In other embodiments, a copy of the completed template 2100 may be stored in the medical record or as the medical record itself. In some embodiments, the patient medical template 2100 may be part of the patient's medical record or otherwise integrated with it.

[0281] Exemplary template 2100 includes predetermined fields 2102, 2104, 2106, 2108, 2110, 2112, 2114, 2116, 2118, and 2120 corresponding to renal failure therapy ("RFT"). Exemplary data acquisition processor 1104 may select template 2100 based on the treatment prescribed for the patient. Although RFT template 2100 is illustrated, the exemplary 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 data acquisition template may include data fields for blood pressure, pulse rate, and weight.

[0282] It should be understood that in other embodiments, the patient medical template 2100 may include additional or fewer fields. For example, template 2100 may also include data fields relating to pre-treatment patient weight and post-treatment patient weight, patient glucose level, and / or patient date of birth. In another example, template 2100 may include fields relating to filling rate, residence time, discharge or fluid removal rate, blood flow rate, outflow rate, ultrafiltration removal rate, dialysate removal rate, total dialysate injected, dialysate flow rate, pre-exchange flow rate, post-exchange flow rate, patient weight balance, return pressure, indication of excess patient fluid, filtration rate, remaining time, dialysate concentration, dialysate name, patient identifier, room identifier, treatment area identifier, timestamp indicating when the data was generated, alarm conditions, alert conditions, and / or events.

[0283] 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 to the data acquisition module 1104 containing the text “Manual replacement.” In response, the data acquisition module 1104 identifies and selects a template 2100 relating to a manual replacement. In another example, the patient may send a message to the data acquisition module 1104 via a personal mobile communication device 200a containing the text “Pre-treatment” or “Start treatment.” In response, the data acquisition module 1104 identifies and selects a template for obtaining the medical information required before treatment is started.

[0284] In the illustrated example of Figure 21, the exemplary data fields include a field 2102 for the patient's name, a field 2104 for the patient identifier, a field 2106 for the patient's weight, a field 2108 for the patient's blood pressure, a field 2110 for the date of treatment, a field 2112 for the amount of UF removed, a field 2114 for the total amount of fluid provided to the patient, a field 2116 for the glucose level, a field 2118 for the treatment prescription identifier, and a field 2120 for the disposable cassette identifier. In the case where the renal therapy machine 90 is registered with the clinician server 200b, the data acquisition module 1104 may remove at least fields 2112-2120 (or select a separate template in which fields 2112-2120 are omitted) because such information has already been provided by the machine 90. However, fields 2112-2180 may be used in the template if the patient has reported manual replacement. Furthermore, template 2100 may omit fields 2102 and 2104 based on at least some of the patient information already registered.

[0285] The exemplary data fields of the patient medical template 2100 may be populated with data from one or more different sources of medical information, including device information, patient information, and / or consumable item information. For example, the patient name field 2102 and the patient identifier field 2104 may be populated with data from an image recorded by the personal mobile communication device 200a of the patient identifier 1012 (or the identifier 1012 worn by the patient). The blood pressure field 2108 may be populated with data 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 with data from an image recorded by the personal mobile communication device 200a of the screen of the weighing scale 106. The date field 2110, the removed UF field 2112, and the fluid filling field 2114 may be populated with data from an image recorded by the personal mobile communication device 200a of the screen (showing the treatment status window) of the home therapy machine 90. Similarly, the glucose level field 2116 may be populated with data from an image recorded by the personal mobile communication device 200a of the screen (showing the settings window) of the home therapy machine 90, and the prescription identifier field 2118 may be populated with data from an image recorded by the personal mobile communication device 200a of the screen (showing the prescription window) of the home therapy machine 90. Finally, the cassette identifier field 2120 may be populated with data from an image recorded by the personal mobile communication device 200a of the identifier 1008 of the disposable cassette consumable item 1006. As discussed above, instead of receiving an image containing medical information, the data acquisition module 1104 may receive one or more messages with text relating to fields 2102-2120.

[0286] The patient medical template 2100, illustrated in Figure 21, is stored on the clinician database 1010 and configured to be accessed by the clinician server 200b, illustrated in Figures 10 and 11. Upon receiving a request to populate a patient template with data, the clinician server 200b is configured to copy the template 2100 or create an instance of it. Medical information received from the personal mobile communication device 200a is populated by the data acquisition module 1104 into the appropriate data fields 2102-2120 of the copy or instance of the template 2100. Upon completion, the copy or instance is stored in the clinician database 1010 repository as the patient's medical record.

[0287] In some embodiments, the data acquisition module 1104 operates routine 2150 in conjunction with, or as an alternative to, the exemplary patient medical template 2100. In some embodiments, routine 2150 may be programmed as metadata or computer executable code relating to the respective data fields 2102-2120. In other examples, routine 2150 may be stored in the clinician database 1010 in relation to the patient medical template 2100. Furthermore, in these other examples, the selection of template 2100 causes routine 2150 to be executed. The exemplary routine 2150 includes routine modules 2152-2164, which provide associations between data fields 2102-2120 and corresponding medical devices, identifiers 1012, and / or consumable items 1006.

[0288] At least some of the routine modules 2152-2164 are associated with or may otherwise be related to a data template (e.g., data template 1700 in Figure 17). The data acquisition module 1104 is configured to access a data template relating to the corresponding routine module 2152-2164 when the patient provides images and / or text in a message. For example, while running routine module 2156 relating to blood pressure, the data acquisition module 1104 transmits a message prompting the personal mobile communication device 200a regarding “systolic blood pressure measurement”. The patient responds with a text message containing an image of the screen or dial of the blood pressure monitor 104. The data acquisition module 1104 is configured to access a data template relating to or referenced by routine module 1156 relating to blood pressure measurement. The data acquisition module 1104 then applies the data template and, using the procedure described above in relation to Figure 16-19, extracts text from the image and identifies relevant systolic blood pressure medical information for input into the blood pressure data field 2108 of template 2100.

[0289] An exemplary routine 2150 may be configured to be initiated based on one or more messages received by the data acquisition module 1104 upon request from the patient. For example, the data acquisition module 1104 may receive a message containing the text “start,” “initiate,” and / or “pre-treatment.” Receipt of the message causes the data acquisition module 1104 to determine and initiate routine 2150 for populating data fields 2102-2120 of template 2100. In another example, the data acquisition module 1104 transmits a first message defined by routine 2150 to the patient at a predetermined time for treatment. After receiving a response message with appropriate medical information from the personal mobile communication device 200a, the data acquisition module 1104 transmits a series of messages defined by routine 2150. In this way, the data acquisition module 1104 controls the acquisition of medical information from the patient according to a predetermined sequence. The data acquisition module 1104 may not transmit the next message in the sequence defined by routine 2150 until an appropriate response message is received from the personal mobile communication device 200a (and medical information is entered into the specified data fields 2102-2120 of template 2100).

[0290] In the illustrated example, the patient band module 2152 may include metadata or a pre-formatted message instructing the patient to record an image of the patient's wristband. The patient band module 2152 may also include character validation checks to ensure that the received medical information conforms to text requirements regarding the patient's name and / or patient identifier. For example, the patient band module 2152 may exclude or discard medical information regarding the patient's name that includes numbers.

[0291] The weighing module 2154 may include metadata or a pre-formatted message instructing the patient to record the identifier 1012c of the weighing instrument 106 in Figure 10 and an image of the screen. The weighing module 2154 may also include character validation checks to ensure that the received medical information is within an acceptable range of values ​​and / or of the correct unit type. In some cases, the weighing module 2154 may use the medical information from identifier 1012c to verify that the medical information from the screen of the weighing instrument 106 is patient weight medical information. In other cases, the medical information from identifier 1012c is used to select a data template, for example, based on the model or type of the weighing instrument 106. The data template is used by the data acquisition module 1104 to identify the relevant weighing instrument medical information extracted from the image of the screen of the weighing instrument 106.

[0292] The blood pressure module 2156 is similar to the weighing scale module 2154 with respect to the blood pressure monitor 104. The renal failure therapy ("RFT") modules 2158-2162 are also similar to the weighing scale module 2154. However, several modules 2158-2162 are used for the home therapy machine 90 (or manual replacement) with respect to each of the different windows where medical information is required. For example, module 2158 provides a message to obtain an image of the first window showing the identifier 1012 of the home therapy machine 90 and the treatment status window, while module 2160 provides one or more messages to obtain an image of the settings window of the home therapy machine 90, and module 2162 provides one or more messages to obtain an image of the prescription window of the home therapy machine 90.

[0293] Cassette module 2164 may contain metadata or a pre-formatted message instructing the clinician or patient to record an identifier 1008, a disposable cassette consumable item 1006, and / or an image of a mark on the packaging or the cassette consumable itself. It should be understood that routine 2150 may contain additional modules if the patient medical template 2100 contains additional data fields, or fewer modules if the template 2100 contains fewer fields.

[0294] When medical information is received using routine 2150, the data acquisition module 1104 of application 1020 uses data validation checks to ensure that the data is within acceptable limits, correctly formatted, and / or in appropriate units. In some cases, modules of routine 2150 may include conversion or formatting instructions, which are used by the data acquisition module 1104 to prepare the medical information for inclusion in the template 2100 and / or the patient's medical record in their respective fields. If 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 patient's medical record in their respective fields.

[0295] In alternative embodiments, the patient medical template 2100 may not have associated routines. Instead, the data acquisition module 1104 in Figure 11 is configured to read data fields 2102-2120 of the patient medical template 2100, for example, to determine 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 prompt the patient regarding the missing data.

[0296] To populate data fields, the data acquisition module 1104 may, in some embodiments, read the names (and any corresponding metadata) of data fields 2102-2120, construct a message prompting the recording of a certain image, and send it to the patient. In one example, the weight data field 2106 contains metadata identifying a weighing scale as the associated medical device. The data acquisition module 1104 determines that data field 2106 is blank, reads the corresponding metadata, and constructs a message instructing the patient on the personal mobile communication device 200a to record an image of the weighing scale screen. In the illustrated embodiment, the data acquisition module 1104 may proceed sequentially through template 2100 (or the patient's medical record), searching for blank data fields and, as appropriate, requesting medical information from the patient via messages displayed by the personal mobile communication device 200a. Alternatively, the data acquisition module 1104 may proceed through template 2100 in a predetermined order or sequence. For example, the data acquisition module 1104 may first search for data fields associated with the patient's wristband, and then search for data fields related to the weighing medical device, the blood pressure medical device, and the renal failure therapy medical device.

[0297] Figure 22 is a schematic diagram of the data acquisition module 1104 of the clinician server 200b of Figure 11, according to an exemplary embodiment of the present disclosure. It should be understood that the illustration of the data acquisition module 1104 is illustrative, and some of the blocks may be combined, further divided, or removed. In addition, in some embodiments, the data acquisition module 1104 may include additional blocks, such as blocks relating to the user interface.

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

[0299] The exemplary data acquisition module 1104 includes a template processor 2204 configured to manage the writing or input of medical information from a personal mobile communication device 200a to a patient medical template 2100 or record. For example, upon request from a patient or clinician, or automatically, the template processor 2204 selects a template from the patient medical template database 2206. The selected template (e.g., template 2100 in Figure 21) is used by the template processor 2204 to operate a routine (e.g., routine 2150) and acquire medical information from the personal mobile communication device 200a, if available or configured.

[0300] The exemplary template processor 2204 is configured to identify messages from modules of routines (e.g., routine 2150) for transmission to a personal mobile communication device 200a. In some cases, messages may be transmitted in a predetermined sequence to direct or guide a clinician or patient through the process of populating a patient medical template with data. For example, the template processor 2204 may determine that a message should be transmitted that reads module 2156 of routine 2150 in Figure 21 and prompts the patient to record an image of identifier 1012c of weighing scale 106. Before identifying the message from routine module 2156 to be transmitted, the template processor 2204 may be configured to wait until medical information associated with identifier 1012c is received (for population into data field 2106 in Figure 21). In other cases, the template processor 2204 selects a message for transmission based on a message received from the personal mobile communication device 200a. For example, the processor 2204 may receive medical information associated with identifier 1012c of weighing scale 106. In response to the received medical information, the template processor 2204 may determine that module 2154 corresponds to the received data and, accordingly, select a message prompting the patient to record an image of the screen of the weighing scale 104. As shown in Figure 22, 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 weighing scale 106.

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

[0302] In some embodiments, the template processor 2204 may receive a stream of messages from a personal mobile communication device 200a containing substantially all medical information for a patient medical template 2100 or a patient medical record. In these embodiments, the template processor 2204 reads indicators, metadata, and / or device data field information provided with the data to determine which data fields of the template 2100 should be populated or written to. For example, the template processor 2204 matches the module metadata or information (or the data fields 2102-2120 themselves) with the indicators, metadata, and / or device data field information provided with the medical information to determine the appropriate data fields of the template 2100.

[0303] After data has been entered into the patient medical template, or after it has been otherwise completed, the template processor 2204 in Figure 22 is configured to store the completed template in the clinician database 1010. This may include using the template 2100 to enter data into the patient's medical record, where fields in the template correspond to, are linked to, or reference to fields in the patient's medical record. In other examples, writing to a medical record may include storing the data-filled template in the patient's medical record, or storing the template 2100 as the medical record itself.

[0304] Figures 23 and 24 are flowcharts of exemplary procedures 2300 and 2350 for populating the medical device template 2100 of Figure 21 with data using images (and / or text messages received therefrom) recorded by the personal mobile communication device 200a of Figures 10-12 and 22, according to an exemplary embodiment of the present disclosure. Procedures 2300 and 2350 are described with reference to the flowcharts illustrated in Figures 23 and 24, but it should be understood that many other ways of performing the steps associated with procedures 2300 and 2350 may also be used. For example, the order of many blocks may be changed, some blocks may be combined with others, and many of the blocks described may be arbitrary. In one embodiment, the order of blocks may be modified if a persistent connection does not exist between the clinician server 200b and the personal mobile communication device 200a. Alternatively, in an embodiment, the personal mobile communication device 200a may first obtain and queue substantially all relevant medical information regarding the patient medical template until (or intentionally) a connection with the clinician server 200b becomes available. The actions described in procedures 2300 and 2350 may be performed, for example, between multiple devices including the personal mobile communication device 200a and the clinician server 200b.

[0305] The exemplary procedure 2300 begins in Figure 23 when the clinician server 200b in Figures 10-12 and 22 receives message 2301 from the personal mobile communication device 200a (block 2302). Message 2301 indicates a request to begin transmitting treatment or medical information to be performed for the patient. The clinician server 200b then determines a patient medical template (e.g., patient medical template 2100 in Figure 21) based on the treatment type specified in message 2301 or the prescribed treatment specified in the patient's medical record (block 2304). In cases where the clinician server 200b provides only one type of template (e.g., a template for renal failure therapy), message 2301 may indicate a request to begin inputting a blank template. In response to message 2301, the clinician server 200b creates a copy of the patient medical template for data input.

[0306] After providing a patient medical template for data input, the clinician server 200b determines at least one medical device for which medical information is required (either by using routines associated with the template or by reading the template itself), and accordingly transmits a first camera message 2305 to the personal mobile communication device 200a (block 2306). The first camera message 2305 includes, for example, an instruction indicating that an image of medical device identifier 1012 should be recorded. After a short time, the clinician server 200b receives a message 2307 containing medical information indicating the type of medical device (e.g., medical information from identifier 1012a) (block 2308). The clinician server 200b then determines a device data template (e.g., device data template 1700 in Figure 17) based on the information contained in message 2307 or information specified in the patient's medical record (block 2310). For example, after message 2307 determines that it identifies a blood pressure monitor 104 (type and / or model), the clinician server 200b determines or finds a device data template for the blood pressure monitor. The clinician server 200b loads the device data template to identify the relevant medical device data from the received image of the blood pressure monitor 104's screen (block 2312).

[0307] The exemplary procedure 2300 continues in Figure 24, with the clinician server 200b transmitting a second camera message 2313 to the personal mobile communication device 200a (block 2314). The second camera message 2313 may be determined based on the type of medical device defined by message 2307. Furthermore, the second camera message 2313 may include information for displaying a window (or associated medical information) on the medical device for recording an image. After a short time, the clinician server 200b receives a message 2315 containing text or an image from the window of the medical device (block 2316). The exemplary clinician server 200b uses an identified data template to extract associated medical information from the image and determines or otherwise identifies the data field in the patient medical template corresponding to the associated medical information (block 2318). If message 2315 contains text, the clinician server 200b determines or otherwise identifies the data field in the patient medical template corresponding to the associated medical information. The clinician server 200b then populates the relevant received medical information into the template determination and / or identified data fields (block 2320).

[0308] After populating the relevant data fields with data, the exemplary clinician server 200b determines whether additional relevant medical information is needed from a medical device associated with the received relevant medical information (decision block 2322). For example, the clinician server 200b may determine that the current medical device may include an additional window or operational display for which relevant medical information is still needed. If additional medical information is needed, the exemplary clinician server 200b returns to block 2314 and transmits a camera message 2313 for another window for which relevant medical information is needed. However, if no additional medical information is needed for the current medical device, the clinician server 200b determines whether the medical information is needed from another medical device (or consumable item 1006) (decision block 2324). If additional medical information is needed, the clinician server 200b returns to block 2306 and transmits a camera message 2305 identifying another medical device for imaging or for receiving relevant medical information. If no additional medical information is required to complete the patient medical template 2100, the exemplary clinician server 200b stores the completed patient medical template 2100 as the patient's medical record in the clinician database 1010, and procedure 2300 terminates.

[0309] Exemplary procedure 2350 is initiated in Figure 23 by the personal mobile communication device 200a transmitting a message 2301 indicating the treatment to be performed on the patient or a request to begin entering medical information (2352). The personal mobile communication device 200a then receives a camera message 2305 from the clinician server 200b. Information from message 2305 is used by the personal mobile communication device 200a to display a prompt to the patient (block 2354). The prompt may specify, for example, that a medical device identifier 1012 should be imaged. The personal mobile communication device 200a then records an image of the medical device identifier 1012 based on the input from the patient (block 2356). In some embodiments, the patient may enter text specifying a medical device type / model or select from a drop-down menu if the identifier is not available or if the patient does not wish (or cannot) to have an image recorded.

[0310] After recording an image of 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 transmits the extracted medical information to the clinician server 200b in message 2307. In some embodiments, the personal mobile communication device 200a instead transmits the recorded image in message 2307.

[0311] Subsequently, the personal mobile communication device 200a receives a camera message 2313 from the server 200b containing information to display to the patient a prompt to record an image of the medical device screen (or other designated area) (block 2360). The personal mobile communication device 200a then displays to the patient a prompt containing information necessary to image the medical device. In response to the prompt, the patient uses the personal mobile communication device 200a to record an image of the medical device screen (or other designated area) (block 2362).

[0312] In Figure 24, the exemplary procedure 2350 continues with the personal mobile communication device 200a creating a text message with a recorded image or text entered by the patient (block 2364). In some examples, the patient may modify or specify medical information. The personal mobile communication device 200a then transmits a message 2315 containing the medical information or an image thereof (block 2366).

[0313] The exemplary personal mobile communication device 200a then determines whether additional relevant medical information is needed from a medical device associated with the extracted relevant medical information (determination block 2368). The determination may include, for example, checking whether additional camera messages related to the current medical device have been received from the clinician server (block 2360). If additional medical information is needed, the exemplary personal mobile communication device 200a returns to block 2360 and processes camera message 2313 with respect to another window (or part of a medical device / consumable item) for which relevant medical information is needed. However, if no additional medical information is needed with respect to the current medical device, the personal mobile communication device 200a determines whether medical information is needed from another medical device (or consumable item 1006) (determination block 2370). If additional medical information is needed, the personal mobile communication device 200a returns to block 2354 and processes camera message 2305 identifying another medical device for imaging. If no additional medical information is required to complete the patient medical template, the exemplary personal mobile communication device 200a terminates the session and thereby terminates procedure 2350.

[0314] (6. Manual / wireless / image-based medical information entry via web browser or file transfer) In some embodiments, the data acquisition module 1104 in Figure 11 is configured to allow a patient to use their personal mobile communication device 200a to input 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 application 1002. In this embodiment, the clinician server 200b hosts websites, APIs, and / or file transfer sites to which addresses or uniform resource locators ("URLs") are assigned. The web browser or file transfer program on the personal mobile communication device 200a is configured to access the hosted websites, APIs, and / or file transfer sites and transmit medical information.

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

[0316] Once the patient gains access via the personal mobile communication device 200a, the data acquisition module 1104, in some embodiments, provides a graphical user interface that prompts the patient regarding medical information and / or images. The user interface may be similar to user interfaces 1400 and 1500 described in relation to Figures 14 and 15. Similar to the personal mobile communication device 200a, which includes application 1002, the clinician server 200b provides a user interface and data fields for receiving medical information. The data acquisition module 1104 may also allow the patient to select a method of data input, such as text or images.

[0317] In some embodiments, the clinician server 200b may provide a menu to allow the patient to select an appropriate user interface. In other embodiments, the clinician server 200b may select a user interface in which medical information is required based on the prescribed treatment or treatment information provided by the patient. In yet another embodiment, application 1020 of the clinician server 200b may operate routine 2150 which provides graphical prompts regarding medical information.

[0318] Figure 25 shows a schematic diagram of a clinician server 200b hosting a website or file transfer site for receiving medical information via images from a personal mobile communication device 200a, according to an exemplary embodiment of the present disclosure. In the illustrated example, the personal mobile communication device 200a is running 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 entering medical information. In this example, the personal mobile communication device 200a records an image 1800 of the screen of a blood pressure monitor 104 in Figure 10. The clinician server 200b applies a data template 1801 to the image and extracts sets of text as shown in fields 1802, 804, 1806, 1808, and 1810. The patient selects fields 1802, 804, 1806, 1808, and 1810, from which the text should be entered into one or more selected data fields on the website 2502. Thus, the clinician server 200b enables patients to provide medical information via a website, file transfer program, or API.

[0319] (C. Data Access Module Embodiment) Turning back to Figure 11, the exemplary data access module 1106 is configured to provide patients and clinicians with access to medical information stored within medical records in the clinician database 1010. As described above in relation to the data acquisition module 1104, there are different possible configurations of the personal mobile communication device 200a, which may or may not have application 1002 installed. Based on the configuration, the data access module 1106 is configured to provide access or otherwise display the data. To determine the configuration used by a particular patient, the exemplary data access module 1106 is configured to access the registration table or the patient's medical records and identify whether the registered personal mobile communication device 200a and / or application 1002 are installed.

[0320] In some embodiments, the data access module 1106 is configured to provide different medical information 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 feature-rich personal mobile communication device 200a, while a second subset of medical information is provided for a feature-scarce personal mobile communication device 200a. Based on registration information, the data access module 1104 determines whether the application 1002 is running on a feature-rich device or a feature-scarce device, and selects the corresponding first or second subset of medical information.

[0321] An exemplary data access module 1106 may determine whether medical and / or treatment information in a patient's medical record should be converted to a different format prior to transmission. For example, medical and / or treatment information may be stored in the medical record in HL7 format. However, this format is not suitable for text messages and / or applications. The exemplary data access module 1106 determines the capabilities of the personal mobile communication device 200a to which the data should be transmitted. The data access module 1106 determines the capabilities based on registration information indicating whether application 1002 is installed and / or whether personal mobile communication device 200a is a feature-rich device. To view the medical information on application 1002, the data access module 1106 uses one or more APIs to convert the medical and / or treatment information from HL7 format to, for example, Hypertext Markup Language ("HTML") format, Java Script Object Notation ("JSON") format, or XML format (e.g., application format). If the data access module 1106 determines that application 1002 is not installed, the data access module 1106 converts the information from HL7 format to, for example, text message or SMS message format via one or more APIs. The exemplary data access module 1106 thus enables patient medical record information to be viewed by the patient regardless of the capabilities of their personal mobile communication device 200a.

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

[0323] Figures 26-29 show schematic diagrams of an application 1002 on a personal mobile communication device 200a that displays medical information provided by an access module 1006, according to an exemplary embodiment of the present disclosure. The application 1002 may be configured to display different user interfaces 2600, 2700, 2800, and 2900, depending on the patient's selection. In some cases, the application 1002 provides a menu or other selectable graphical feature that enumerates the different user interfaces available. The application 1002 may be configured to receive medical information via one or more APIs linked to data fields in the patient's medical record. In other words, the medical information from the patient's record is plugged into a blank template that defines a graphical user interface for displaying the medical information.

[0324] The user interface 2600 in Figure 26 provides a first graph 2602 illustrating the total removed UF per day and a second graph 2604 illustrating the average removed UF per separate day / night exchange. It should be understood that the medical information displayed in graphs 2602 and 2604 may originate from the home therapy machine 90 and / or one or more medical devices. The data access module 1106 of the clinician server 200b provides access to medical information from different sources, as long as the information is already stored in the patient's medical record, thereby providing information transparency to the patient.

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

[0326] The exemplary user interface 2700 in Figure 27 illustrates the average drainage time for each UF exchange. Drainage times are provided in Graph 2702. Between user interfaces 2600 and 2700, the patient can measure how the treatment is progressing over time. Any deviations in treatment will be easily apparent and should help persuade the patient to adhere to the prescribed therapy.

[0327] An exemplary user interface 2800 includes a calendar showing days on which the patient complied with treatment or therapy compared to days on which the patient did not. The patient may select one of those days to view additional medical information. For example, user interface 2900 shows treatment or medical information for April 26. The information includes the total amount of UF removed during that day, in addition to a breakdown of UF removed during manual replacement compared to UF removed via the home therapy machine 90. In the illustrated embodiment, the machine therapy information includes the program name, prescribed therapy time, actual therapy time, and the amount of UF removed. The data access module 1106 may determine whether the therapy was complied with based on whether the actual therapy time is within the threshold of the prescribed therapy time. In some embodiments, the data access module 1106 and / or the data acquisition module 1104 may determine compliance at the time the medical or therapy information is received and set a corresponding flag or other instruction in the patient's medical record to reflect compliance or non-compliance.

[0328] In some examples, treatment information regarding manual exchanges is entered by the patient via application 1002 on a personal mobile communication device 200a, while machine-operated treatment information is received separately from the home therapy machine 90. In other examples, the user interface 2900 may display treatments performed at the patient's home and treatments performed at the clinic. The information may be organized based on the machine from which the information was received, 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 removed UF for different exchanges, thereby providing patient information regarding the effectiveness of manual exchanges compared to machine-operated exchanges. The exemplary system 100 in Figure 10 allows information from both exchanges to be stored together (based on the date of treatment) for subsequent display and / or analysis.

[0329] (2. Embodiment of information display via a web browser) In some embodiments, the personal mobile communication device 200a may not have 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 and / or treatment information on one or more web pages, similar to the user interfaces 2600-2900 in Figures 26-29. In this embodiment, the personal mobile communication device 200a accesses the data access module 1106 via a website. The selection of a user interface or feature via the personal mobile communication device 200a causes the data access module 1106 to display medical information within the web page. The data access module 1106 may be configured to format or render the medical 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 may request a username and password from the patient prior to providing access to the website.

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

[0331] In one example, data access module 1106 may receive a text message containing the text "Send 7 days of UF data." In response, data access module 1106 identifies the patient record corresponding to the phone number of the personal mobile communication device 200a from which the text message was received. Data access module 1106 may then use a lookup table or keyword search to identify a field in the patient's medical record that contains a matching set of characters or text related to UF data (e.g., "7 days of UF"). Data access module 1106 copies the matching text and creates a reply message with UF values ​​for the previous 7 days, which is transmitted to the personal mobile communication device 200a. In addition, or alternatively, data access module 1106 may create and render a 7-day graph, similar to graph 2602 in Figure 26. Data access module 1106 creates an image of the graph, which is transmitted to the personal mobile communication device 200a as an image in the text message. The image may be stored as a file such as .jpeg, .gif, or .png. A patient using a personal mobile communication device 200a may view graphs via text messages. Thus, the exemplary data access module 1106 is configured to provide patient access to medical and therapeutic information regardless of the capabilities and / or operating system of its own personal mobile communication device 200a. In addition, the data access module 1106 determines how data should be transmitted based on instructions as to whether registration information and / or applications 1002 provided by the patient are installed on the patient's personal mobile communication device 200a.

[0332] (4. Alarm / Alert Implementation Methods) In addition to providing a display of medical and / or treatment information, the exemplary data access module 1106 in Figure 11 is configured to determine and / or generate alarms and / or alerts for patients and / or clinicians. The data access module 1106 may transmit alarms and / or alerts to the patient's personal mobile communication device 200a or the clinician device 152. In some embodiments, the data access module 1106 may include a rule table that specifies which devices certain alarms / alerts should be transmitted to. The clinician may use the clinician device 152 to subscribe to certain alarms / alerts and / or patients.

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

[0334] In some embodiments, the data access module 1106 includes, or has access to, a data structure or list that defines certain conditions under which an alarm or alert should be generated. In one example, the condition may compare a single data value or trend (e.g., a 30-day moving average) to an acceptable range of values ​​and / or thresholds (which may include hard and / or soft limits). In other examples, the alarm or alert may be generated based on multiple conditions that compare different types of information to their respective limits. In some cases, the data access module 1106 determines derived information calculated from treatment and / or medical information, which is then compared to an acceptable range. The following provides examples of alarms / alerts that may be transmitted by the data access module 1106 via text messages and / or displayed within application 1002.

[0335] In one example, the data access module 1106 may generate an alarm or alert if it detects that a patient is beginning to deviate from prescribed treatment. For example, after detecting that two days have passed since treatment information was received, the data access module 1106 (operating according to alert rules) transmits an alert message to the personal mobile communication device 200a. The alert message may, for example, stipulate that the patient should perform the treatment. The alert message may also include information (or a link to information) explaining why the treatment is important or what will happen to the patient's body if the treatment is not performed in a timely manner. If the data access module 1106 detects, for example, that no treatment information has been received for four days, the data access module 1106 escalates the alert to an alarm (operating according to alarm rules). The data access module 1106 transmits the alarm to the personal mobile communication device 200a and / or the clinician device 152, providing instructions on the severity of the non-compliance with treatment. As mentioned above, alarms and / or alerts may be transmitted by the data access module 1106 based on whether application 1002 is installed. Even if application 1002 is installed, the data access module 1106 is configured to transmit a text message to the personal mobile communication device 200a to draw the patient's attention.

[0336] In some cases, patients are prescribed manual replacements. Therefore, patients need to provide treatment information indicating a manual replacement. The data access module 1106 is configured to transmit an alarm or alert if manual replacement information is not received within a predetermined period (e.g., within 2 days after the scheduled treatment). Furthermore, if the manual replacement is not properly completed (e.g., short filling or dwell time), the data access module 1106 sends an alert and / or alarm regarding the inadequate replacement. To determine an inadequate replacement, the data access module 1106 may compare the filling, dwell time, and / or drain time to pre-established acceptable ranges and / or thresholds. In some cases, the data access module 1106 may require the patient to perform a complete replacement.

[0337] In one example, an alarm and / or alert may be generated to indicate that the patient should select a different treatment program from several prescribed treatment programs or that a treatment program should be adjusted. In this example, the alarm or alert rule may stipulate that the data access module 1106 should calculate the accumulated fluid value and compare it to a certain threshold, while comparing the patient's blood pressure or weight to a corresponding threshold. The accumulated fluid value may be determined from individual fluid filling and draining volumes, and it indicates the fluid remaining in the patient's abdominal cavity. If the blood pressure or weight and the accumulated fluid value (or trend) are outside an acceptable range, the data access module 1106 generates an alarm. The alarm may indicate that the patient is accumulating fluid and that a treatment program with a longer draining duration (or a shorter filling duration) should be selected (or the treatment program should be adjusted to provide a longer draining duration or a shorter filling duration). The data access module 1106 transmits the alarm for display on a personal mobile communication device 200a. The patient may respond via application 1002 or text message, prompting the clinician server 200b to make appropriate changes to the patient's prescription or therapy program.

[0338] In some embodiments, alarms and / or alerts may define conditions under which additional information should be prompted from the patient. In these embodiments, the data access module 1106 uses therapeutic information from the home therapy machine 90 as a basis for determining whether the patient should provide medical information via the personal mobile communication device 200a. In one example, the data access module 1106 may have access to alarm and / or alert rules that define conditions under which a prompt or text message prompting for an additional weight or blood pressure measurement is sent to the patient's personal mobile communication device 200a. For example, an alarm or alert may define that a prompt for a new blood pressure measurement is required if the blood pressure value (or trend) exceeds a predetermined threshold. In another example, an alarm or alert may define that a prompt for a new blood pressure measurement is required if the accumulated fluid value or removed UF value (or trend) is outside an acceptable range. In response, the data access module 1106 transmits a text message or notification via application 1002 for the patient to perform and record the blood pressure measurement. In some cases, application 1002 may open a user interface (e.g., user interface 3000 in Figure 30) that prompts the patient to enter blood pressure information. If additional data received from personal mobile communication device 200a is not within acceptable limits, data access module 1106 may escalate the alert to an alarm transmitted to clinician device 152 and / or personal mobile communication device 200a. Thus, data access module 1106 is configured to operate rules that determine borderline patient conditions that prompt for additional information from the patient before determining whether further attention or action is requested by the clinician or patient.

[0339] In a further embodiment, rules in the data access module 1106 may instruct the patient to inspect the home therapy machine 90 and / or make changes to it. In one example, the rules may stipulate that if treatment information has not been received from the home therapy machine 90 within a defined period (e.g., two days), the data access module 1106 should transmit an alert to the patient. In this situation, the patient may have provided medical information indicating that treatment has been performed, and the data access module 1106 may use this to determine that an alert regarding adherence to treatment is not necessary. Instead, the data access module 1106 may determine that an alert should be transmitted to the patient to check the network connectivity of the home therapy machine 90 so that the treatment information stored on the machine 90 can be read. The patient may respond to the alert using a personal mobile communication device 200a to indicate that the connectivity has been checked. After receiving the response from the patient, the data access module 1104 may send a PIN message to the home therapy machine 90 regarding the missing treatment information. If a connection still cannot be established, the data access module 1106 may send an alert to the patient, clinician, and / or network administrator with more specific instructions to activate the home therapy machine 90 and / or to overcome the network connectivity problem.

[0340] In another example, the data access module 1106 may include one or more rules specifying that an alert should be generated in response to treatment information being out of range. For example, a large difference between the fluid filling volume and the discharge volume may indicate leakage in the dialysis tubing or the connection to the patient. In response, the data access module 1106 transmits an alert to the patient prompting them to verify the fluid connection. The patient may provide a response indicating whether leakage was detected. In response, the data access module 1106 determines whether the leakage was corrected in a subsequent treatment cycle (or primary sequence) or whether the tubing should be replaced. Based on treatment and / or medical information, the data access module 1106 may determine similar consumable issues relating to cassettes, cartridges, etc. For example, a small volume of removed UF may prompt the data access module 1106 to transmit an alert for the patient to verify the concentration of the dialysis fluid and / or concentrate connected to the home therapy machine 90.

[0341] (D. Therapeutic control module embodiment) The exemplary treatment control module 1110 in Figure 11 is configured to allow the patient and / or clinician to modify prescriptions and / or programs on the home therapy machine 90. To operate, the home therapy machine 90 is assigned one or more prescriptions for the patient. A prescription may specify the type of treatment (e.g., automated peritoneal dialysis, manual exchange treatment, hemodialysis, etc.), the duration for which the patient should receive treatment, the glucose level or other concentrate level of the treatment fluid, the daily amount of UF to be removed, and / or the number of times per day or the duration range for each treatment. Each prescription may include one or more programs. A program may specify the duration of treatment, the total volume of fluid to be delivered to the patient, the number of refill, retention, and drainage cycles to be repeated, and / or instructions on whether the treatment includes tidal therapy. Differences in programs within a prescription allow the patient or clinician to modify certain treatment parameters based on the patient's condition or activity.

[0342] Prescriptions and associated programs are stored in the electronic prescriptions section of the clinician database 1010. In some embodiments, prescriptions may be stored in the patient's medical records. The home therapy machine 90 is programmed with one or more prescriptions. Programming may be performed locally via the clinician or patient, or remotely from the clinician server 200b. For example, the clinician server 200b (e.g., the treatment control module 1110) may, after registration, send a copy of the prescription from the clinician database 1010 to the home therapy machine 90.

[0343] In some embodiments, the exemplary treatment control module 1110 operates in conjunction with an application 1002 on a personal mobile communication device 200a and / or an application on a clinician device 152, and is configured to allow the patient and / or clinician to select different prescription programs and / or prescriptions. Figure 31 shows a schematic diagram of the user interface 3100 of application 1002, which allows the patient to choose between three different programs, namely a short-term program, a long-term program, and a weekend program. The patient may select a program based on their activity and / or circumstances. In some embodiments, application 1002 may display alerts from a data access module 1106 that provide recommendations to change the program based on detected fluid buildup, weight gain, or higher blood pressure.

[0344] 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. Furthermore, the treatment control module 1110 transmits a message to the home therapy machine 90 providing instructions to change to the selected program. In some cases, the message may include treatment parameters for the newly selected program. The home therapy machine 90 then performs the next treatment based on the newly selected program. In some cases, the home therapy machine 90 may prompt the patient to confirm the new program before operating according to the program.

[0345] In some embodiments, the treatment control module 1110 may perform checks to verify whether the patient is authorized to change the program and / or whether the change is permitted. For example, the treatment control module 1110 receives instructions from a patient who wishes to change from a short-term program to a long-term program. The treatment control module 1110 compares the patient's medical information against one or more thresholds to ensure that the change will not adversely affect the patient. For example, the treatment control module 1110 may not approve the change from a short-term program to a long-term program if the patient has already accumulated a relatively large volume of fluid. If the change cannot be made, the treatment control module 1110 sends a message to the personal mobile communication device 200a indicating the reason why the change cannot be made.

[0346] In one embodiment, the treatment control module 1110 may send a notification to the clinician device 152 indicating that the patient wishes to change the program. The treatment control module 1110 may not communicate the change to the home therapy machine 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 treatment control module 1110. In these embodiments, the treatment control module 1110 may send a message for display in the application 1002 of the personal mobile communication device 200a indicating that the change has been made in the program and / or that the clinician has made the change.

[0347] In cases where the personal mobile communication device 200a does not include application 1002, the treatment control module 1110 is configured to allow changes to the prescription. For example, the treatment control module 1110 may host a website accessible by a web browser on the personal mobile communication device 200a. The website may include features similar to the user interface 3100 in Figure 31 to allow the patient to remotely select different programs and / or prescriptions.

[0348] In addition, or alternatively, the treatment control module 1110 is configured to allow treatment changes via text messages. In one example, a patient may send a message from a personal mobile communication device 200a containing the text “Change treatment.” In response, the treatment control module 1110 is configured to send a reply message with different treatment program options and corresponding codes or indicators next to each option. The patient may enter indicators or codes within the reply message to select the desired program. In another example, a patient may send a message to the treatment control module 1110 containing, for example, the text “Long-term program” to cause the program to be changed to a long-term program.

[0349] (E. Implementation of Education Modules) The exemplary educational module 1108 in Figure 11 is configured to provide educational materials and / or encouragement to patients via a personal mobile communication device 200a. Similar to the other modules 1102-1106 and 1110 in Figure 11, the educational module 1108 is configured to provide content / information based on the configuration of the personal mobile communication device 200a. For example, if application 1002 is installed, the educational module 1108 is configured to select and provide educational materials through application 1002. If the application is not installed, the educational module 1108 is configured to provide educational materials via a website and / or text message. In the text message case, the educational module 1108 may be configured to structure the educational materials to fit within the text message, or to provide links to educational materials in the clinician database 1010, or educational materials hosted by a third-party server.

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

[0351] As described herein, incentives include text, audio, video, or multimedia presentations designed to improve the patient's mood or help the patient comply with the program. Incentives may also include rewards or badges. In some embodiments, the education module 1108 may be configured to provide incentives based on detected conditions. In some cases, incentives may be provided in combination with alerts generated by the data access module 1106. In some examples of incentives, different status levels may be provided to the patient based on the rate of compliance (e.g., a "dialysis superstar" for near-perfect compliance).

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

[0353] In one example, the data access module 1106 determines that a patient is not complying with their treatment. In addition to the data access module 1106 sending an alert, the education module 1108 may recommend or provide a link to a video about the importance of compliance. Figure 32 shows an exemplary user interface 3200 of application 1002 that displays compliance-related educational videos provided by the education module 1108. The exemplary user interface 3200 also provides a list of recommended educational materials based on the detected conditions of the patient. For example, after detecting from medical records or receiving as medical information that a patient has hypertension, the education module 1108 is configured to recommend educational content about lowering blood pressure. Furthermore, after detecting that a patient has not changed their prescribed program, the education module 1108 determines that educational content explaining program options should be recommended.

[0354] An exemplary educational module 1108 may detect how the patient interacts with application 1002 and recommend educational content. For example, educational module 1108 receives feedback from application 1002 indicating that the patient has made multiple attempts to populate a data field in a user interface (e.g., user interface 14 in Figure 14) using recorded images. In response, educational module 1108 may provide a notification via application 1002 recommending that the patient view a tutorial on information input using recorded images.

[0355] The exemplary educational module 1108 may store any educational content or encouraging instructions displayed by a personal mobile communication device 200a in the patient's medical record. Such information may be useful to clinicians in determining how the patient is engaging with their treatment. The stored information may also provide guidance on the patient's awareness of their treatment.

[0356] (F. Auxiliary Module Embodiment) The exemplary auxiliary module 1112 in Figure 12 is configured to create a communication session between a patient and their clinician. Specifically, the auxiliary module 1112 is configured to create a communication session between a clinician device 152 and a personal mobile communication device 200a. The auxiliary module 1112 may use the capabilities of the personal mobile communication device 200a to determine an appropriate communication session.

[0357] A communication session may include a video session, audio call, conference call, SMS session, or web messaging session. If application 1002 is installed, auxiliary module 1112 may have access to options for selecting a video session, conference session, or web messaging session to connect the patient to the clinician through application 1002. If application 1002 is not installed, auxiliary module 1112 may be limited to options related to the inherent communication capabilities of the personal mobile communication device 200a, such as text messaging and audio calls.

[0358] In some embodiments, the patient may initiate a session. Application 1002 is configured to allow the patient to request contact with a clinician (including specifying a preferred method of communication). Using the text features of Application 1002, the patient may send a text message containing the text “Help” to the Auxiliary Module 1112 to initiate a session. After the patient requests to initiate a session, the Auxiliary Module 1112 is configured to identify an available clinician. In some embodiments, the Auxiliary Module 1112 may find a record of a clinician associated with the patient and send a PIN / request message to that device. A response received from one of the devices 152 provides an indication that a clinician is available and willing to communicate with the patient. In some cases, the response may indicate the clinician’s method of communication. In response to the received message, the Auxiliary Module 1112 initiates a communication session. This may include establishing a web call, messaging session, or audio call between the personal mobile communication device 200a and the clinician device 152. In some embodiments, instead of broadcasting a PIN message to a group of clinicians, the auxiliary module 1112 may sequentially send PIN / request messages to clinicians according to a predetermined order (e.g., first, the most important clinician; second, the on-call clinicians in the same office; third, the on-call clinicians in different offices, etc.). Figure 33 shows a schematic diagram of the user interface 3300 of application 1002 that provides a video session with a clinician. The video session allows the patient to address their concerns regarding their treatment. The video session also allows the clinician to view the real-time settings of the treatment or assists the patient in setting up the treatment.

[0359] In some embodiments, the auxiliary module 1112 may determine or recommend that a communication session be opened. The auxiliary module 1112 may provide recommendations in conjunction with the data access module 1106 generating alarms and / or alerts. After detecting conditions relating to alerts and / or alarms, the auxiliary module may identify a clinician device 152 available to join the session and then initiate a call to a personal mobile communication device 200a to address the alerts and / or alarms. In one example, the auxiliary module 1112 may attempt to create a communication session after detecting that a patient's blood pressure, weight, accumulated fluid, etc., exceeds a predetermined threshold or has changed significantly within a predetermined period.

[0360] The exemplary assistance module 1112 may determine the type of assistance requested in order to identify the correct individual for connection. In addition to clinicians, the assistance module 1112 may be able to connect with information technology professionals and home therapy machine professionals. Before initiating a session, application 1002 may 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 may determine the type of assistance based on the context in which the session requirements were received. For example, after reviewing an educational training program about home therapy machine 90, the assistance module 1112 may determine that the subsequent request for assistance concerns operating home therapy machine 90. In another example, while application 1002 is displaying a user interface related to UF tendencies, the assistance module 1112 may determine that the subsequent request for assistance concerns a clinical problem.

[0361] An exemplary auxiliary module 1112 may be configured to log communication sessions in the patient's medical record. The auxiliary module 1112 may record the date / time of the communication session and instructions on how the session was initiated. The record may also include participants in the communication session and minutes of the communication. With respect to text messages, this may include copies of the messages. With respect to audio or video, this may include recordings of calls or transcripts of calls.

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

Claims

1. A system for transmitting treatment information from a home therapy machine, wherein the system is: Clinician server, A personal mobile communication device including an application that stores 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 is, (i) It is possible to be communicatively connected to the clinician server via a separate internet connection defined by the second registration information, and (ii) it is possible to be communicatively connected to the personal mobile communication device via a local connection, It is configured to transmit treatment information related to renal failure therapy administered to the patient as prescribed by the prescription, Home therapy devices and A clinician database that is communicatively connected to the clinician server, wherein the clinician database is configured to store the treatment information from the home therapy machine in the patient's electronic medical record. Equipped with, The home therapy device is configured to transmit the treatment information to the personal mobile communication device when the second registration information is unavailable or the separate internet connection is unavailable. A system in which the application on the personal mobile communication device is configured to use the first registration information to transmit the treatment information to the clinician server for storage in the clinician database in the patient's electronic medical record.

2. The system according to claim 1, wherein the application is configured to convert the treatment information into Health Level 7 ("HL7") format before transmitting the treatment information to the clinician server.

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

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 defining at least one of a patient activation code ("PAC"), information indicating the personal mobile communication device, or a patient identifier, and the registration information is used by the clinician server to communicate with the application and to store the treatment information in the patient's electronic medical record.

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

6. The system according to claim 1, wherein the treatment information includes at least one of blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual replacement data, consumable data relating to consumable items, volume data of injected fluid, amount of ultrafiltration ("UF") removed from the patient, amount of renal failure therapy fluid used during the renal failure therapy treatment, treatment time, alarms, alerts, or 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 is communicably coupled to the home therapy machine via at least one of the following: a wireless local area network ("WLAN"), a LAN, a Bluetooth® connection, a Wi-Fi® connection, a Zigbee® connection, a Z-Wave® connection, or a wireless universal serial bus ("USB") connection.

9. The clinician server is configured to transmit a new prescription to the application on the personal mobile communication device when registration information relating to the home therapy machine is unavailable. The system according to claim 1, wherein the personal mobile communication device is configured to transmit the new prescription to the home therapy machine with respect to subsequent renal failure therapy.

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

11. A method for transmitting treatment information from a home therapy machine, wherein the method is: The first registration information for communicating with the clinician server via an internet connection is stored in a personal mobile communication device, The second registration information for communicating with the aforementioned personal mobile communication device is stored within the home therapy machine, The home therapy device generates treatment information related to renal failure therapy provided to patients as prescribed by the prescription, The home therapy device determines that direct communication with the clinician server via a separate internet connection is not possible, After determining that direct communication with the clinician server via the aforementioned separate internet connection is not possible, the generated treatment information is transmitted from the home therapy machine to the personal mobile communication device using the second registration information. Using the first registration information, the treatment information is transmitted from the personal mobile communication device to the clinician server. Methods that include...

12. The method according to claim 11, further comprising storing the treatment information in the patient's electronic medical record in a clinician database via the clinician server.

13. The method according to claim 12, wherein the clinician database is configured to store registration information in a patient registration file, the registration information defining at least one of a patient activation code ("PAC"), information indicating the personal mobile communication device, or a patient identifier, and the registration information is used by the clinician server to store the treatment information in the patient's electronic medical record.

14. The method according to claim 11, further comprising converting the treatment information to a health level 7 ("HL7") format via the personal mobile communication device before transmitting the treatment information to the clinician server.

15. The method according to claim 11, wherein the first registration information includes at least one of the following: the internet address of the clinician server, the identifier of the clinician server, application programming interface ("API") information for connecting to the clinician server, or the identifier of at least one of the patient or the home therapy machine.

16. The home therapy machine includes at least a renal failure therapy machine or an infusion pump, The method according to claim 11, wherein the treatment information includes at least one of blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual replacement data, consumable data relating to consumable items, volume data of injected fluid, amount of ultrafiltration ("UF") removed from the patient, amount of renal failure therapy fluid used during the renal failure therapy treatment, treatment time, alarms, alerts, or diagnostic information.

17. The method according to claim 11, wherein the personal mobile communication device is a smartphone, a cellular phone, or a tablet computer.

18. The method according to claim 11, wherein the personal mobile communication device is communicably coupled to the home therapy machine via at least one of a wireless local area network ("WLAN"), LAN, Bluetooth® connection, Wi-Fi® connection, Zigbee® connection, Z-Wave® connection, or Wireless Universal Serial Bus ("USB") connection.

19. The method described above is: When registration information for the aforementioned home therapy device is unavailable, a new prescription is transmitted from the clinician server to the personal mobile communication device. Regarding subsequent renal failure therapy, the new prescription is transmitted from the personal mobile communication device to the home therapy machine. The method according to claim 11, further comprising:

20. The method according to claim 11, wherein the home therapy machine transmits the treatment information to the personal mobile communication device only after the renal failure therapy treatment has been completed or discontinued.

Images