Medical fluid delivery system including mobile platform 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 technology]

[0001] Engaging patients outside of a medical setting for extended periods of time is currently a virtually impossible task. Similar to signing up for a gym membership or purchasing a treadmill, many patients typically rush into the process. For example, from the start, patients are likely to readily adopt self-administered medical treatments (e.g., medical fluid delivery treatments) in their own homes. Regarding treatment, patients need to connect themselves to a medical fluid delivery machine (or a container containing renal failure treatment fluid) to cleanse their blood from toxin buildup. Part of the treatment may include tasks that the patient needs to perform, such as weighing themselves, measuring their blood, and / or recording information related to their treatment. Information recorded by the patient is often reviewed by a clinician to ensure that treatment is progressing as prescribed. Clinicians also review the recorded data to determine whether adjustments to treatment are needed.

[0002] Over time, many patients become disengaged from treatment as the treatment loses its novelty and becomes a mundane obligation. As can be imagined, patients would rather engage in activities that are more exciting, relaxing, or stimulating compared to self-administered medical treatment. As patients continue their treatment, they sometimes begin to skip performing the additional tasks associated with treatment. Omitting additional tasks and becoming disengaged has the potential to create gaps in clinical oversight regarding ongoing treatment. As patients become more disengaged from treatment, they may begin to skip treatments or forgo them entirely, endangering their health in the process. Summary of the Invention [Means for solving the problem]

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

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

[0005] Additionally, the exemplary medical fluid data transfer system provides a gateway for clinicians to allow patients to communicate with clinicians in real time regarding any concerns or questions about their medical fluid delivery treatment. In some embodiments, the medical fluid data transfer system also provides patient access to educational or training materials. Thus, the exemplary medical fluid data transfer system is configured to connect patients to the assistance they need or require to remain involved and / or compliant with their treatment.

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

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

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

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

[0010] In a first aspect of the present disclosure, which may be combined with any other aspects enumerated herein unless otherwise specified in light of the disclosure herein and without limiting the disclosure in any way, a machine-accessible device has stored thereon instructions that, when executed, are configured to cause a machine to populate patient medical records of a clinical system by: operating a camera to record images; operating a display interface; operating a connection interface configured to connect to a clinician database, the clinician database being configured to store patient medical records; and operating a processor to acquire medical information. The processor is operated to acquire the medical information by displaying, via the display interface, a user interface with fields into which the medical information should be entered, and, after selection of a data field in the user interface, graphically providing, via the display interface, a first option for entering the medical information from an image and a second option for entering the medical information via text input. If the first option is selected, the processor receives a recorded image from the camera, the recorded image including a medical device or a screen of the medical device, extracts text from the image, and enables selection of at least a portion of the text from the image via the display interface and writes the selected text from the image into a data field of the user interface as medical information. If the second option is selected, the processor enables text entry into the data field as medical information via the display interface. The processor is also operated to retrieve the medical information by transmitting the medical information written into the data field to a patient medical record stored in a clinician database after the send instruction is received.

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

[0012] According to a third aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, the data template is configured to define a context for extracted text relative 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 stated, the machine-accessible device further comprises instructions stored thereon configured to, when executed, cause the processor to operate the machine to determine a data template based on at least one of: (i) selection of a medical device type via a user interface; (ii) information scanned from an identifier located on the medical device; and (iii) indicia in the extracted text; or (iv) relative positioning of the extracted text.

[0014] According to a fifth aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, the identifier located on the medical device includes at least one of a quick response (“QR”) code, a barcode, a serial number, or a hardware number located on a housing of the medical device or a screen of the medical device.

[0015] According to a sixth aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, 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 weight scale, and a heart rate monitor.

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

[0017] According to an eighth aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, the consumable item includes at least one of a filter, a blood line set, a dialysate concentrate container, a blood anticoagulant container, a drug container, a disposable cassette, a sorbent cartridge, and a water purification container.

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

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

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

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

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

[0023] According to a fourteenth aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, a first image is received at a processor via a first text message or a first short messaging service (“SMS”) message, and a second image is received at a processor via a second text message or a second SMS message.

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

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

[0026] According to a seventeenth aspect of the present disclosure, which may be used in combination with any other aspects enumerated herein unless otherwise stated, a system for transmitting information to a patient includes a patient's home therapy machine configured to transmit treatment information, and a clinician database configured to store medical records and a registration file that identifies the home therapy machine and the patient's personal device as registered devices and identifies whether the personal device has installed an application for viewing the treatment information and medical information. The system also includes a clinician server communicatively coupled to the clinician database, the home therapy machine, and the personal device. The clinician server is configured to store the treatment information and medical information in the medical records, receive an indication that at least a portion of the treatment information 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 the application is installed, the clinician server is configured to convert at least a portion of the treatment information and medical information into an application format for display in the application and transmit the converted at least a portion of the treatment information 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 information and medical information into a text message or short messaging service (“SMS”) format and transmit the converted at least a portion of the treatment information and medical information to the personal device via one or more text messages or SMS messages.

[0027] According to an eighteenth aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, the application format includes at least one of an Extensible Markup Language ("XML") format or a 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 enumerated herein unless otherwise stated, the instruction that at least some of the treatment information and medical information should be displayed on the 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 enumerated herein unless otherwise stated, the registration file is contained 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 enumerated in this specification unless otherwise stated, a 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 a 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 to transmit program instructions to the home therapy machine for changing from the first program to the second program.

[0031] In the twenty-second aspect of the present disclosure, any of the structures and functionality disclosed in connection with FIGS. 1-33 may be combined with any other structure and functionality disclosed in connection with FIGS. 1-33.

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

[0033] It is another advantage of the present disclosure that it provides an improved patient lifestyle.

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

[0035] It is yet another advantage of the present disclosure that it provides improved mechanical efficiency.

[0036] It is yet a further advantage of the present disclosure that it provides improved patient compliance.

[0037] It is yet another advantage of the present disclosure to provide a medical fluid data transfer system and methodology that can be applied to different types of medical fluid delivery machines.

[0038] It is yet a further advantage of the present disclosure to provide a medical fluid data transfer system and methodology that allows communication between a medical fluid delivery machine and multiple persons, such as a patient and a clinician or a patient and a primary caregiver.

[0039] Additionally, it is an advantage of the present disclosure to reduce waste of disposable sets and other ancillary textile products due to disposal, which often occurs when the machine timer expires.

[0040] The advantages discussed herein may be found in one or some, but perhaps not all, of the embodiments disclosed herein. Additional features and advantages will be described herein and will be apparent from the following detailed description and figures. The present invention further provides, for example, the following: (Item 1) 1. A machine-accessible device storing instructions that, when executed, are configured to cause a machine to populate a patient medical record of a clinical system, the populating of the patient medical record comprising: Activating a camera and recording an image; operating a display interface; operating a connection interface configured to connect to a clinician database, the clinician database configured to store patient medical records; Operate the processor and acquire medical information; Therefore, Obtaining the medical information includes: displaying, via said display interface, a user interface with fields in which medical information is to be entered; graphically providing, via the display interface after selection of a data field in the user interface, a first option for entering medical information from an image and a second option for entering medical information via text input; If the first option is selected, receiving a recorded image from the camera, the recorded image including a medical device or a screen of a medical device; extracting text from the image; enabling selection of at least a portion of the text from the image via the display interface; writing the selected text from the image as the medical information in the data field of the user interface; and and If the second option is selected, enabling text entry of the data field as the medical information via the display interface; After a transmission command is received, transmitting the medical information written into the data field to a patient medical record stored in the clinician database. by a machine-accessible device. (Item 2) and instructions stored on the machine-accessible device, the instructions being configured, when executed, to cause the processor to: determining a data template for the extracted text on the image; processing the extracted text using the data template to categorize the extracted text into fields; enabling selection of at least one of the fields and writing the selected text from the image into the data field of the user interface; Item 1. The machine-accessible device of item 1, (Item 3) 3. The machine-accessible device of claim 2, wherein the data template is configured to define a context for the extracted text relative to a text position within the image. (Item 4) 3. The machine-accessible device of claim 2, further comprising instructions stored on the machine-accessible device that, when executed, are configured to cause the processor to operate to determine the data template based on (i) a selection of a medical device type via the user interface, (ii) information scanned from an identifier located on the medical device, and (iii) at least one of indicia within the extracted text, or (iv) a relative positioning of the extracted text. (Item 5) Item 5. The machine-accessible device of item 4, wherein the identifier located on the medical device includes at least one of a quick response ("QR") code, a barcode, a serial number, or a hardware number located on a housing of the medical device or on the screen of the medical device. (Item 6) Item 10. The machine-accessible device of item 1, wherein the 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 weight scale, and a heart rate monitor. (Item 7) Item 1. The machine-accessible device of item 1, wherein the data field of the user interface is configured to receive at least one of blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual replacement data, subjective data, or consumable data related to a consumable item. (Item 8) 8. The machine-accessible device of item 7, wherein the consumable items include at least one of a filter, a blood line set, a dialysate concentrate container, a blood anticoagulant container, a drug container, a disposable cassette, a sorbent cartridge, and a purified water container. (Item 9) Item 10. The machine-accessible device of item 1, wherein the machine is a personal mobile communications device. (Item 10) 1. A method of populating a patient medical record in a clinical database using recorded images, the method comprising: transmitting a first message to a personal device, the first message prompting the patient to record a first image of a medical device using a camera of the personal device; receiving the first image from the personal device; determining, via a processor, first medical information from the first image indicative of a type or model of the medical device; determining, via the processor, a data template and a second message associated with the determined type or model of the medical device; transmitting, via the processor, the second message to the personal device, the second message prompting the patient to use the camera to record a second image of the screen of the medical device; receiving the second image from the personal device via the processor; extracting text from the second image via the processor; and processing the extracted text using the data template via the processor to categorize the extracted text into fields; writing, via said processor, at least a portion of said text from at least one of said fields into said patient medical record; A method comprising: (Item 11) determining, via said processor, a correspondence between one of said fields and a record field within said patient medical record; writing, via the processor, the at least a portion of the text from the field into the record field in the patient medical record; Item 11. The method of item 10, further comprising: (Item 12) determining, via said processor, a treatment time from said patient medical record; transmitting the first message via the processor prior to the treatment time; Item 11. The method of item 10, further comprising: (Item 13) receiving, at the processor, a therapy message from the personal device indicating that the patient should begin therapy; transmitting the first message via the processor before the treatment is initiated; Item 11. The method of item 10, further comprising: (Item 14) Item 11. The method of item 10, wherein the first image is received at the processor via a first text message or a first short messaging service ("SMS") message, and the second image is received at the processor via a second text message or a second SMS message. (Item 15) 11. The method of claim 10, further comprising, via the processor, converting the at least a portion of the text from at least one of the fields into Health Level 7 ("HL7") format before writing to the patient medical record. (Item 16) comparing, via the processor, the at least a portion of the text from at least one of the fields to a predetermined range; writing, via the processor, the at least a portion of the text from at least one of the fields if the at least a portion of the text from at least one of the fields is within the predetermined range; Item 11. The method of item 10, further comprising: (Item 17) 1. A system for transmitting information to a patient, the system comprising: a home therapy machine for the patient configured to transmit therapy information; a clinician database configured to store the medical records and a registration file, the registration file identifying the home therapy machine and the patient's personal device as registered devices and whether the personal device has installed an application for viewing the treatment information and the medical information; a clinician server communicatively coupled to the clinician database, the home therapy machine, and the personal device; Equipped with The clinician server: storing the treatment information and the medical information in the medical record; receiving an indication that at least a portion of the treatment information and the medical information should be displayed on the personal device; determining from the registration file whether the application is installed on the personal device; If the application is installed, converting the at least some of the treatment information and medical information into an application format for display within the application; transmitting the transformed at least a portion of the treatment information and the medical information to the personal device; and If the application is not installed, converting the at least a portion of the treatment information and the medical information into a text message or short messaging service ("SMS") format; transmitting the converted at least a portion of the treatment information and medical information to the personal device via one or more text or SMS messages; To do A system that is configured to: (Item 18) Item 18. The system of item 17, wherein the application format includes at least one of an Extensible Markup Language ("XML") format or a Hypertext Markup Language ("HTML") format. (Item 19) Item 18. The system of item 17, wherein the instruction that at least a portion of the treatment information and medical information should be displayed on the personal device includes at least one of a message from the application or a text / SMS message from the personal device. (Item 20) Item 18. The system of item 17, wherein the registration file is contained within 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 administer a therapy, and the clinician server: receiving a program message from the personal device indicating a change from a first program to a second program; transmitting program instructions to the home therapy machine to change from the first program to the second program; Item 18. The system of item 17, configured to: [Brief explanation of the drawings]

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

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

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

[0044] [Figure 4] FIG. 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] FIG. 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] FIG. 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] FIG. 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 with a mobile communication device application in a first state.

[0048] [Figure 8] FIG. 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 with a mobile communication device application in a second state.

[0049] [Figure 9] FIG. 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 with a mobile communication device application in a third state.

[0050] [Figure 10] FIG. 10 illustrates a second embodiment of a medical fluid data transfer system.

[0051] [Figure 11] FIG. 11 shows a diagram illustrating the operational modules of an application on the clinician server of the medical fluid data transfer system of FIG. 10 according to an embodiment of the present disclosure.

[0052] [Figure 12] FIG. 12 shows a diagram illustrating communication between the home therapy machine of FIGS. 10 and 11, a personal mobile communication device, and a clinician server, according to certain exemplary embodiments of the present disclosure.

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

[0054] [Figure 14] 14 and 15 show diagrams illustrating the user interface of the application of FIG. 11 according to an exemplary embodiment of the present disclosure. [Figure 15] 14 and 15 show diagrams illustrating the user interface of the application of FIG. 11 according to an exemplary embodiment of the present disclosure.

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

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

[0057] [Figure 18] FIG. 18 shows a diagram illustrating filling in data fields of the user interface of FIG. 14, according to an exemplary embodiment of the present disclosure.

[0058] [Figure 19] FIG. 19 is a flow diagram of an exemplary procedure for entering medical information from an image using the application of the personal mobile communication device of FIGS. 10 and 11, according to an exemplary embodiment of the present disclosure.

[0059] [Figure 20] FIG. 20 illustrates an example of a user interface displayable by an application on the personal mobile communication device of FIGS. 10 and 11 that allows a patient to provide recorded images, according to an exemplary embodiment of the present disclosure.

[0060] [Figure 21] FIG. 21 shows a schematic diagram of a patient medical template used by the clinician server of FIGS. 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] FIG. 22 is a schematic diagram of a data acquisition module of the clinician server of FIG. 11, according to an exemplary embodiment of the present disclosure.

[0062] [Figure 23]23 and 24 are flow diagrams of an exemplary procedure for populating the medical device template of FIG. 21 using images recorded by (and / or text messages received from) the personal mobile communication device of FIGS. 10 and 11, according to an exemplary embodiment of the present disclosure. [Figure 24] 23 and 24 are flow diagrams of an exemplary procedure for populating the medical device template of FIG. 21 using images recorded by (and / or text messages received from) the personal mobile communication device of FIGS. 10 and 11, according to an exemplary embodiment of the present disclosure.

[0063] [Figure 25] FIG. 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 FIGS. 10 and 11, according to an exemplary embodiment of the present disclosure.

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

[0065] [Figure 30]FIG. 30 shows a schematic diagram of the personal mobile communication device of FIGS. 10 and 11 prompting a patient regarding medical information, according to an exemplary embodiment of the present disclosure.

[0066] [Figure 31] FIG. 31 shows a schematic diagram of the personal mobile communication device of FIGS. 10 and 11 providing a patient with a program regarding medical treatments to select, according to an exemplary embodiment of the present disclosure.

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

[0068] [Figure 33] FIG. 33 shows a schematic diagram of the personal mobile communication device of FIGS. 10 and 11 providing a video chat session between a patient and a clinician, according to an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0069] A medical fluid delivery system is disclosed herein. The exemplary medical fluid delivery system is configured to improve patient engagement with medical treatments, such as medical fluid delivery treatments. The medical fluid delivery system is configured to provide patients with greater transparency regarding and at least some control to direct their own treatment, while 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 feature set of medical devices associated with the treatment or the patient's personal mobile communication device. Such a configuration allows the disclosed medical fluid delivery system to be compatible with virtually any patient situation.

[0070] In some embodiments, the 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 at a self-service medical facility. The clinician server is communicatively coupled to the personal mobile communication device and / or the medical fluid delivery machine via a wide area network (i.e., the Internet). The clinician server is configured as a hub that enables the personal mobile communication device to provide features designed to engage patients with medical fluid delivery treatments.

[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 personal mobile communication devices, allowing patients to track their treatment progress. In addition, patients may use their personal mobile communication devices to change (or request changes to) their treatment programs. The requests are routed through the clinician server to verify that the changes are appropriate before being transmitted to the medical fluid delivery machine.

[0072] The 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, medical device data, etc. The personal mobile communication device is configured to enable patients to manually enter data, record photographs containing data from, and / or wirelessly receive data from, connected medical devices, such as weighing scales, blood pressure monitors, thermometers, glucose meters, etc. The collected data is stored in the patient's medical record. In some embodiments, the clinician server and / or the personal mobile communication device may use templates to determine how the received data should be automatically populated into the patient's medical record.

[0073] As disclosed herein, a personal mobile communication device may include a feature-rich smart device such as a smartphone or tablet computer. The smart device may operate specialized applications (e.g., "apps") defined by instructions stored in memory. Execution of the stored instructions causes the smart device to process the applications, which are configured to improve patient engagement with medical treatment. In some cases, a personal mobile communication device may include a reduced-feature traditional cellular phone that includes significantly less processing power and features compared to a smart device. The cellular device may operate using text messages and / or specialized applications (e.g., apps) defined by instructions stored in memory. Applications for the reduced-feature device may have fewer features compared to applications for a smart device.

[0074] The following disclosure is separated into two sections: the first section discloses certain embodiments of a medical fluid delivery system, and the second section discloses features that enable the medical fluid delivery system to improve patient engagement and / or compliance with medical treatment.

[0075] I. MEDICAL FLUID DELIVERY SYSTEM EMBODIMENTS An exemplary medical fluid delivery system includes one or more medical fluid delivery machines. One example of a medical fluid delivery machine is a renal failure treatment machine. With respect to a renal failure treatment machine, due to various causes, a patient's renal system is unable to function. Renal failure results in several physiological disturbances. It is no longer possible to maintain water and mineral balance or excrete daily metabolic loads. Toxic end products of nitrogen metabolism (urea, creatinine, uric acid, and others) can accumulate in the blood and tissues.

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

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

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

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

[0080] Most HD (HF, HDF) treatments are performed in centers. A trend toward home hemodialysis ("HHD") exists today, in part because HHD can be performed daily, offering therapeutic benefits over in-center hemodialysis treatments (typically performed two or three times per week). Studies have shown that frequent treatments remove more toxins and waste products than patients who receive less frequent, but perhaps longer, treatments. Patients who receive more frequent treatments do not suffer as many downcycles as in-center patients who accumulate two or three days' worth of toxins prior to treatment. In some areas, the nearest dialysis center can be many miles from the patient's home, resulting in door-to-door treatment times that consume a large portion of the day. HHD can be performed overnight or during the day while the patient relaxes, works, or is otherwise productive.

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

[0082] There are various types of peritoneal dialysis treatments, including continuous ambulatory peritoneal dialysis ("CAPD"), automated peritoneal dialysis ("APD"), and tidal flow dialysis, and continuous flow peritoneal dialysis ("CFPD"). CAPD is a manual dialysis treatment. In this, the patient manually connects an implanted catheter to a drain to allow spent or spent dialysate fluid to drain from the peritoneal cavity. The patient then connects the catheter to a bag of fresh dialysis fluid to infuse fresh dialysis fluid into the patient through the catheter. The patient disconnects the catheter from the fresh dialysis fluid bag, allowing the dialysis fluid to dwell in the peritoneal cavity, and transfer of waste, toxins, and excess water occurs. After a dwell period, the patient repeats the manual dialysis procedure, for example, four times per day, with each treatment lasting approximately one hour. Manual peritoneal dialysis requires a significant amount of time and effort from the patient and leaves room for improvement.

[0083] Automated peritoneal dialysis ("APD") is similar to CAPD in that the dialysis treatment involves drain, fill, and dwell cycles. However, APD machines typically perform the cycles automatically while the patient sleeps. APD machines relieve patients from having to manually perform treatment cycles and from the need to transport supplies during the day. APD machines are fluidly 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, and into the patient's peritoneal cavity. APD machines also allow the dialysis fluid to dwell within the cavity, allowing transfer of waste, toxins, and excess water to occur. The source may include multiple sterile dialysis fluid bags.

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

[0085] Any of the above modalities performed by the machine may be performed on a scheduled basis and may require a start-up procedure. For example, dialysis patients typically perform treatment on a scheduled basis, such as every other day, daily, etc. Blood treatment machines typically require a certain amount of time before treatment for setup, for example, to perform a disinfection procedure. Patients for the above modalities lead busy lives and may have plans to perform or errands to run on the day their treatment is scheduled.

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

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

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

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

[0090] Alternatively, or in addition, it is envisioned that communication software may be configured to automatically program reminders onto a user's mobile communication device, for example, into the device's native task tracking feature, such as a calendar application. Most smartphones are provided with a calendar that separates each day into time segments, such as hours. The software of the disclosed system and methodology may be programmed to access an authorized patient's and / or caregiver's smartphone calendar and populate the appropriate time segment of the appropriate day with the appropriate information, e.g., that a machine will begin or complete disinfection within that time segment.

[0091] In one embodiment, communication from the software system and methodology of the present disclosure is unidirectional. For example, communication can be from a medical fluid delivery machine, which can be a home machine, to a patient's or caregiver's mobile communication device. In an alternative embodiment, the software system and methodology of the present disclosure allows for bidirectional communication between the medical fluid delivery machine and the patient's or caregiver's mobile communication device. In one example, bidirectional communication can allow certain machine routines to be remotely initiated by the patient or caregiver using their mobile communication device. One exemplary routine is an automated self-test routine, which can be performed without any user interaction with the system other than initiating or starting the sequence. Initiating a sequence remotely can benefit the patient or caregiver, for example, by providing additional time during which the patient or caregiver can step away from the machine to perform other tasks. Communication is bidirectional when the machine initiates communication by indicating that it is ready to perform a self-test routine. The patient or caregiver responds to the machine via the software system and methodology of the present disclosure at the desired time to initiate the sequence.

[0092] It is envisioned that whenever a machine is in the "patient connected" software state, the software of the disclosed system and methodology will disable communications 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 the middleware software application so that the command is not forwarded to that machine. The middleware software application may then reply to the clinician informing them that the machine is busy and will not accept communications.

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

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

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

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

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

[0098] Electronic medical record ("EMR") databases at clinics or hospitals 126a-126n store electronic information about patients. System hub 120 may transmit data collected from machine 90 log files to hospital or clinic databases 126a-126n to merge or supplement the patient's medical record. Databases at clinics or hospitals 126a-126n may contain patient-specific treatment and prescription data; therefore, access to such databases may be highly restricted. Enterprise resource planning system 140 acquires and compiles data generated through patient and clinician website access, such as complaints, billing information, and lifecycle management information. Web portal 150 allows patients and clinics 152a-152n that treat them to access publicly available websites for users of medical fluid delivery machines 90. Business intelligence portal 160 collects data from system hub 120 and provides the data to marketing 162, research and development 164, and quality / pharmacovigilance 166.

[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 component programs may be provided as a series of computer instructions on any conventional computer-readable medium, including random access memory ("RAM"), read-only memory ("ROM"), flash memory, magnetic or optical disks, optical memory, or other storage media. The instructions may be configured to be executed by a processor, which, upon execution of the series of computer instructions, performs or facilitates the performance of all or a portion of the disclosed methods and procedures.

[0100] In one embodiment, home therapy machine 90 administers home therapy, such as home hemodialysis, to a patient in the patient's home and then reports the results of that therapy to clinicians, doctors, and nurses involved in managing the patient's health and well-being.

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

[0102] In one embodiment, the home therapy machine 90 uses a connectivity service, e.g., 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 therapy machine 90 to the connectivity server 118 via the modem 102. The home therapy machine 90 in one embodiment accesses the Internet using a separate, e.g., 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 therapy machine 90 and launched on the machine's ACPU 50. One suitable connectivity service is provided by Axeda®, which provides a securely managed connection 116 between the medical device and the connectivity server 118.

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

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

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

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

[0107] The medical fluid delivery machine 90 of FIG. 2 includes a blood circuit 20. The blood circuit 20 draws blood from and returns blood to the patient 12. Blood is drawn from the patient 12 via an arterial line 14 and returned to the patient via a venous line 16. The arterial line 14 includes an arterial line connector 14a, which connects to an arterial needle 14b, which provides blood withdrawal communication with the patient 12. The venous line 16 includes a venous line connector 16a, which connects to a venous needle 16b, which provides blood return communication with the patient. 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 are automatically closed 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 sense air in the arterial and venous lines 14 and 16, respectively. If air is detected by one of the air detectors 22a and 22v, the system 10 closes the line clamps 18a and 18v, pauses the blood and dialysis fluid pumps, and provides instructions to the patient to purge the air so that treatment can resume.

[0109] In the illustrated embodiment, a 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, the blood pump pods 30a and 30b are each blood containers, which include, for example, a spherical, rigid outer shell with a flexible diaphragm located within the shell, forming a diaphragm pump. One side of each diaphragm receives blood, while the other side of each diaphragm is operated by positive and negative air pressure. The blood pump 30 may alternatively be a peristaltic pump operating with the arterial line 14 or multiple peristaltic pumps operating with the arterial line 14 and the venous line 16.

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

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

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

[0113] The dialysis fluid circuit 70 is again greatly simplified in FIG. 2 for ease of illustration. An actual dialysis fluid circuit 70 would include all of the relevant structures and functionality described in the publications incorporated by reference above. Certain features of the dialysis fluid circuit 70 are illustrated in FIG. 2. In the illustrated embodiment, the dialysis fluid circuit 70 includes a hemofilter dialysis fluid pump 64. The pump 64, in one embodiment, 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 again may be spherically configured. The two pump pods are alternately operated, as with the blood pump 30, such that one pump pod fills with HD dialysis fluid while the other pump pod expels HD dialysis fluid.

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

[0115] A fifth pod pump (not shown) provided in drain line 82 is used to remove a known amount of ultrafiltrate ("UF") as HD therapy is delivered. System 10 tracks the UF pump to control and keep track of the amount of ultrafiltrate removed from the patient. System 10 ensures that the required amount of ultrafiltrate is removed from the patient by the end of therapy.

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

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

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

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

[0120] In the illustrated embodiment, the medical fluid delivery machine 90 is a continuous, continuous-flow system that pumps dialysis fluid through the hemofilter once and then pumps the used dialysis fluid to drain. Both the blood circuit 20 and the dialysis fluid circuit 70 can be hydrodisinfected 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 hydrodisinfected and reused daily for approximately one month, while the dialysis fluid circuit 70 is hydrodisinfected and reused for approximately six months.

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

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

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

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

[0125] B. Exemplary Medical Fluid Delivery System Connectivity Embodiments Referring now to Figure 4, a system 110a of the present disclosure is illustrated. System 110a in the illustrated embodiment operates in conjunction with system 10 described above, which includes a connectivity server 118, a system hub 120, a service portal 130, an enterprise resource planning system 140, a web portal 150, and a business intelligence portal 160, which are illustrated as part of a cloud environment in Figure 4. Each of connectivity 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 the cloud environment or may be located 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, medical fluid delivery machines 90a and 90b may reside separately within the homes of patients 12a and 12b (shown as being outside the homes). Alternatively, medical fluid delivery machines 90a and 90b may reside within the same clinic 126a-126n or within different ones of clinics 126a-126n. Clinicians 112a and 112b may reside within or outside the clinic.

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

[0128] In one embodiment, the mobile communication devices 200a and 200b download application software (“apps”) from middleware software stored on the system hub 120 via their connection to the Internet 52. The apps are updated whenever there is a change in the status of the corresponding machine 90a or 90b. For example, the medical fluid delivery machine 90a may have just completed its automated self-test routine and is now ready to perform a sterilization procedure. The machine 90a may generate a code identifying this status and send it to the middleware software stored on the system hub 120. The middleware software then converts the code, using, for example, a lookup table, into a message such as “Self-test completed, ready to sterilize,” and causes the message to be displayed in an 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 particular status to which the machine 90a belongs. The app may also provide any one or more of audio alerts, such as a "beep" sound, and / or tactile alerts, such as vibrations, that prompt the patient 12a or clinician 112a to consult the app and confirm the change in status of the machine 90.

[0129] In another example, a medical fluid delivery machine 90b may be preprogrammed to begin treatment at 3:00 PM. The medical fluid delivery machine 90b may require three hours for self-testing and disinfection. The patient 12a or clinician 112a therefore needs to be present at the machine 90b by noon to begin pre-treatment. In one embodiment, the patient 12a or clinician 112a configures the machine 90b regarding how far in advance of the three-hour preparation period the patient 12a or clinician 112a should be notified or alerted (e.g., two hours). Thus, in this example, the machine 90b may generate a code at 10:00 AM and send the code to middleware software stored on the system hub 120. The middleware software then converts the code, for example, using a lookup table, into a message such as "Please begin treatment preparation in two hours" and causes the message to be displayed in an app downloaded to the patient 12b's or clinician's 112b's mobile communication device 200b. The app may again be programmed to provide a visual identifier, such as a countdown timer counting down from 120 minutes to a timeout at zero, along with a message. The app may also provide any one or more of an audio alert, such as a "beep" sound and / or a haptic alert, such as a vibration, that prompts the patient 12b or clinician 112b to consult the app and confirm the treatment preparation notification. The app may also be programmed to repeat the "beep" sound and / or haptic feedback at preprogrammed intervals (e.g., 1 hour and 30 minutes) during the countdown period.

[0130] In addition to, or as an alternative to, providing an app on the user's communication device 200b, it is envisioned that middleware software in the system hub 120 converts the code from the machine 90b into a message that is embedded on the device's 200 native task-tracking feature, such as its calendar application. Most smartphone devices 200 are provided with a calendar that separates each day into time segments, such as hours, for example. Here, the message converted by the system hub 120 middleware software can be programmed to access the authorized communication device's 200b calendar and populate the appropriate time segment for the appropriate day with the appropriate information. In the above example, for the appropriate day, the native calendar software application would have its 10:00:00 AM time slot filled with a message such as "Please begin treatment preparation in 2 hours." Audio and / or tactile feedback signals can be provided to notify the patient 12 or clinician 112 of the calendar entry.

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

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

[0133] System hub 120 in one embodiment stores middleware software that can be accessed by mobile communication device 200 (shown as a single device for simplicity, although multiple devices 200 may be connected to system 110b as well). Mobile communication device 200 of FIG. 5 includes all of the structure, functionality, and alternatives (including being connected to Internet 52) ​​disclosed with respect to devices 200a and 200b illustrated in FIG. 4. In FIG. 5, mobile communication devices 200 may, but need not, download software applications (“apps”) from middleware software stored on system hub 120 via their connection to Internet 52. The apps may be operated exactly as described above in connection with FIG. 4 (including middleware software that converts coded messages from machine 90 into a format presentable on the app). Alternatively, or in addition, middleware software stored on system hub 120 may be capable of converting code from machine 90 into a message that is embedded on a native task-tracking feature of mobile communication device 200, such as its calendar application, in any of the ways described in FIG. 4.

[0134] Further alternatively or additionally, system 110b includes cellular network 210 interfacing between middleware software stored in system hub 120 and mobile communication device 200, for example. Cellular network 210 may include a network of cellular telephone towers that operate using radio waves and / or may employ satellites. Communication protocols suitable for use with cellular network 210 of system 110b may be long-range protocols such as (i) the "Worldwide Interoperability for Microwave Access" ("WiMAX") protocol and (ii) the "Global System for Mobile Communications" ("GSM") protocol, which is a wide-ranging long-range wireless protocol that enables data communication to many of the cellular telephones worldwide. Network 210 may alternatively or additionally employ a medium-range protocol such as a wireless local area network ("WLAN"), which may be a protocol that is part of the Institute of Electrical and Electronics Engineers ("IEEE") 802.11 standard, such as (i) IEEE 802.11a, (ii) IEEE 802.11b, (iii) WEE 802.11g, or (iv) 802.11n. Other suitable cellular technologies may include CDMA, AMPS (analog), General Packet Radio Service ("GPRS"), cdmaOne, CDMA2000, Evolution Data Optimized ("EV-DO"), Enhanced Data Rates for GSM Evolution ("EDGE"), Universal Mobile Telecommunications System ("UMTS"), Digital Cordless Telecommunications Standard ("DECT"), Digital AMPS ("IS-136 / TDMA"), and Integrated Digital Enhanced 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 Short Messaging Service ("SMS") or Multimedia Messaging Service ("MMS") protocols. The middleware software in the system hub 120 may communicate with the cellular network 210 in several ways. In one example, the phone number and carrier of a user 12, 112 (any or all of the patient 12, the patient's home care partner, and the patient's clinician 112) is associated with a particular machine 90, for example, via a lookup table in the middleware software. When a message / code from a particular 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®, patient 001's machine 90 sends a message to the middleware software of system hub 120, which, upon receipt, is programmed to relay the email to 5555555555@att.net, which is received as a text message by patient 001's mobile communication device 200. Those skilled in the art will appreciate that there are multiple websites dedicated to informing people how to send email to text messages and outlining the details required by different carriers.

[0136] The middleware software stores each of the phone numbers of each of the mobile communication devices 200 and matches each of those numbers with a machine 90. When an event code is sent from the 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 to an appropriate message using, for example, a lookup table as described above, and sends the converted message to the called phone number. It is envisioned that multiple communication devices 200 may be associated with the same medical fluid delivery machine 90. For example, in any of 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 environment, the phone numbers of the patient 12 and the patient's clinician and / or caregiver assistant may be associated with the same machine 90.

[0137] Similarly, a telephone number for the mobile communication device 200 may be associated with multiple medical fluid delivery machines 90. For example, a single nurse may monitor multiple machines 90 at any of the clinics 126a-126n. If an event occurs at 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 more detail below in connection with Figures 7-9.

[0138] The cellular message may convey information about any of the same events discussed above with respect to the software app and calendar update mode that populates information into the mobile communication device 200. For example, the 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 converts the code, e.g., using a lookup table, into a message such as "Self-test completed, ready to disinfect," and causes, e.g., the cellular output routine discussed above, to send a text message to the mobile communication device 200 of the patient 12 or clinician 112 and display the message. In an alternative embodiment, a code is not required, and the machine 90 instead sends the actual text string, which the middleware software forwards to the mobile communication device 200 as a text message, e.g., via the cellular output routine discussed above. As is known, receipt of a text message on a communication device 200 may be accompanied by an audio, e.g., a "beep" 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 PM. The medical fluid delivery machine 90 may again require three hours for self-testing and disinfection. The patient 12 or clinician 112 must therefore be present at the machine 90 by noon to begin pre-treatment. In one embodiment, the patient 12 or clinician 112 configures the machine 90 as to how far in advance of the three-hour preparation period the patient 12 or clinician 112 should be notified or alerted (e.g., two hours). Here, the machine 90 generates a code at 10:00 AM and sends the code to middleware software stored on the system hub 120. The middleware software then converts the code, e.g., using a lookup table, into a message such as "Please begin treatment preparation in 2 hours" and causes, e.g., the cellular output routine discussed above to send a text message to the mobile communication device 200 of the patient 12 or clinician 112 and display the message along with an audio alert, e.g., a "beep" sound and / or a tactile alert, e.g., a vibration, that prompts the patient 12 or clinician 112 to view the notification.

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

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

[0142] System hub 120 in one embodiment stores middleware software that can be accessed by mobile communication device 200 (shown as a single device for simplicity, although multiple devices 200 may be connected to system 110b as well). Mobile communication device 200 of FIG. 6 includes all of the structure, functionality, and alternatives (including being connected to Internet 52) ​​disclosed with respect to devices 200a and 200b illustrated in FIG. 4. In FIG. 6, mobile communication devices 200 may, but need not, download software applications (“apps”) from middleware software stored on system hub 120 via their connection to Internet 52. The apps may be operated exactly as described above in connection with FIG. 4 (including middleware software that converts coded messages from machine 90 into a format presentable on the app). Alternatively, or in addition, middleware software stored on system hub 120 may be capable of converting code from machine 90 into a message that is embedded on a native task-tracking feature of mobile communication device 200, such as its calendar application, in any of the ways described in FIG. 4. The calendar application may alternatively be updated via the cellular network 210 (alternatively illustrated via dashed lines in FIG. 6) discussed above in connection with FIG.

[0143] 6 illustrates that communication can 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 can be via the Internet 52 and / or the cellular network 210. Communication between the middleware software in the server computer 120 can be via the connection server 118 over a securely managed connection 116, as described in detail above.

[0144] As discussed above, the home therapy machine 90 connects to the connectivity server 118 through its onboard connectivity agent 114, which in one embodiment is turned off during treatment, e.g., while the machine 90 and its peripherals are functioning (it may or may not be turned off during post-treatment disinfection). This prevents the home therapy machine 90 from communicating with any entity and sending or receiving data during treatment and disinfection, or when the machine 90 is operational or running. It is assumed that communications through the systems 110a-110c are secured in the same manner. For example, assume that a particular machine 90 is configured via middleware software to communicate with both the patient 12 and the clinician 112. It is assumed here that when a patient is being treated by the machine 90, the connectivity agent 114 is shut off so that the clinician 112 does not receive notifications from or can send commands to the machine 90 during that time. In an alternative embodiment, the clinician 112 may be able to receive notifications from the machine 90 during treatment.

[0145] Determining when to disconnect (no communication) the connectivity agent 114 may depend on the content or number of machine conditions that the systems 110a-110c desire to communicate to the mobile communication device 200. For example, assume it is only desired to inform the patient 12 or clinician 112 two hours before treatment preparation that they need to return to the machine 90 to begin treatment preparation. Here, the connectivity agent 114 may be turned off as soon as the patient 12 or clinician 112 begins the first treatment preparation step, e.g., performs 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 preset 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 connectivity agent 114 may be disconnected when the patient 12 or clinician 112 begins machine disinfection. In a further example, it may be desirable for the machine 90 to notify the patient 12 when disinfection is complete so that the patient can begin treatment within a certain amount of time from the end of disinfection and disinfection does not have to be repeated. Here, the connectivity agent 114 may be disconnected when the patient 12 or clinician 112 begins treatment, for example, at the beginning of priming when the patient is not yet connected to a treatment line, e.g., the arterial line 14 or the venous line 16.

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

[0148] In an alternative embodiment, the patient 12 or clinician 112 may enter a known code in a text message that selects a particular action to be performed on the machine 90, such as a self-test routine or disinfection procedure. The code may be a suggestive code, such as “self-test” or “disinfect.” The text message is transmitted via the cellular network 210 to middleware software in the system hub 120. The middleware software converts the text code, for example, via a lookup table, into an action code for the selected action. Alternatively, the code entered by the patient 12 or clinician 112 may be an action code so that no conversion is required. In either case, the action code is transmitted via the connectivity server 118 and securely managed connection 116 to the machine 90 whose connectivity agent 114 is on, allowing the action code for the selected action to be transmitted to the machine's ACPU 50, which initiates performance of the selected action.

[0149] 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 for the patient 12 to begin initiating an automated self-test routine (e.g., a two-hour period) of the machine 90. In step 2, the middleware software application in the system hub 120 sends a corresponding (e.g., translated) message to the patient's mobile communication device 200 indicating that the machine 90 is ready for the patient 12 to begin initiating an automated self-test routine.

[0150] In step 3, the custom app downloaded to the patient's mobile communication device 200 alerts the patient 12 via audio, visual, and / or tactile alerts and associated messages that the patient's machine 90 is ready for the patient to begin initiating, for example, a two-hour automated self-test routine. In step 4, the 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 wants to start its automated self-test routine. In step 6, the middleware software application in the system hub 120 sends (e.g., converts and transmits) a message to the machine 90 indicating that the patient 12 has confirmed that the machine 90 wants to start its automated self-test routine. In step 7, the machine 90 starts and performs its automated self-test routine.

[0152] Once the self-test is performed, it is envisioned that the system 110c performs 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 the patient 12 reminding the patient the amount of time they have before returning to the machine 90 to begin treatment. It should be understood that different types of medical fluid delivery machines may have one, two, three, or more different actions that the patient 12 or clinician 112 may perform before treatment begins.

[0153] For systems 110a-110c, it is envisioned that apps on mobile communication devices 200 will be programmed to be configurable by users to select the types of notifications they wish to receive on their devices 200, for example, via the apps themselves, via text messages, and / or via calendar notifications. System hub 120, in one embodiment, may send all notification types, with mobile communication device 200 ignoring communication types that the user has disabled. System hub 120, in another embodiment, remembers the user's preferences and sends only information in the selected notification types.

[0154] C. Clinician Device / Server Embodiments 7-9, one embodiment of a system 110d having a clinician-based downloadable software application (“app”) 230 for a doctor, clinician, or nurse's mobile communication device or server 200 is illustrated on screens 232-236. As discussed above, the mobile communication device 200 may be that of a patient 12 or that of a doctor / nurse / clinician 112. Screens 232-236 of FIGS. 7-9 illustrate that the app 230 may be used in a clinic or hospital 126a-126n, for example, where a nurse is responsible for multiple machines 90a-90n. The machines 90a-90n may again be hemodialysis machines, peritoneal dialysis machines, CRRT machines, drug and / or nutritional fluid delivery machines, and combinations thereof.

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

[0156] It is envisioned that the app 230 operates with the system hub 120 as discussed herein, and that the system hub 120 is remote from the clinics or hospitals 126a-126n and maintained, for example, by the manufacturer of one or more of the machines 90a-90n. The app 230 may, for example, initially be developed in product development 128 illustrated in FIG. 1. The app 230 may then be sent from product development 128 to the system hub 120 via a service portal 130 as illustrated in FIGS. 1 and 7. Any nurse, clinician, or doctor 112 authorized to download the app 230 may do so from the system hub 120. The system hub 120 then maintains the middleware software to operate with the app 230 in the manner described above in the systems 110a-110c.

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

[0158] Middleware software in the system hub 120 or local system hub 220 updates the status of each machine 90a-90n. A nurse, clinician, or doctor 112 can select an icon 190a-190n at any time to see the current status of each machine 90a-90n, for example, "Idle," "Self-Test," "Disinfect," or "Treat Patient" as illustrated in screen 234 of FIG. 8. Other status markers are also envisioned and may differ for different types of machines. The nurse, clinician, or doctor 112 can then select any of "Idle," "Self-Test," "Disinfect," or "Treat Patient" to return to the home icon 190a-190n as illustrated in FIG. 9.

[0159] As discussed above, it is contemplated that the connectivity agent 114 of each machine 90 is turned off when the machine is powered on, particularly when a patient 12 is connected to the machine. However, it is also contemplated that the connectivity agent 114 of each machine 90a-90n in the clinics 126a-126n may remain on until the end of disinfection so that middleware software in the system hub 120 or local system hub 220 may receive a status change to "treating patient" from each machine 90a-90n. Additionally, since each machine 90a-90n knows its scheduled treatment period, the machine may send the scheduled duration to the middleware software, which may then send the duration in the form of a countdown timer along with the status change to "treating patient." Here, when a nurse, clinician, or doctor 112 then selects "treating patient" in FIG. 8, they may see a countdown timer indicating the remaining time of treatment, as illustrated in FIG. 9.

[0160] With respect to countdown timers, it is envisioned that the connectivity agent 114 enables the machines 90a-90n to transmit remaining time data to the system hub 120 so that the app 230 can display the actual remaining time for each machine 90 undergoing a timed process. The app 230 accounts for alarms or other delays that the machine 90 may experience. During an alarm condition, the corresponding icon 190a-190f may display a message such as "Alarm" or "Safe Mode." The nurse, clinician, or doctor 112 can then select the countdown time in FIG. 9 to return to the home icons 190c, 190d, and 190h illustrated in FIG. 7.

[0161] The nurse, clinician, or doctor 112 may toggle the alert on / off icon 238 to enable or disable visual, audible, and / or tactile alerting of status changes regarding the machines 90a-90n. If the alert on / off icon 238 is toggled “on,” the app 230 on the mobile communication device 200 will provide a visual, audible, and / or tactile alert, e.g., (i) “self-test started,” (ii) “self-test completed,” (iii) “disinfection started,” (iv) “disinfection completed,” (v) “treatment started,” and (vi) “treatment completed,” each time a machine status changes. In one embodiment, codes for (i)-(v) are sent via machines 90a-90n through securely managed connections 116, connectivity server 118, and system hub 120 or local system hub 220, translated by middleware software, and forwarded to app 230, which updates the appropriate icon 190. In various embodiments, "(vi) Treatment Complete" is either (a) sent via machines 90a-90n with an activated connectivity agent 114, or (b) inferred when the countdown timer of the appropriate icon 190a-190n expires and the connectivity agent 114 may still be off.

[0162] When the alert on / off icon 238 is toggled off, for example, if the nurse, clinician, or doctor 112 does not wish to be interrupted at a given moment, the icons 190a-190n are still updated as described above, but no audible and / or tactile alerts are provided. However, the nurse, clinician, or doctor 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 buttons 240 or generally individually as action buttons 240). Any number of action buttons 240 may be provided for any type of pre-treatment action required for any modality, e.g., hemodialysis, peritoneal dialysis, CRRT, drug and / or nutritional fluid delivery. In the illustrated embodiment, action button 240a is for initiating a self-test on machine 90, while action button 240b is for initiating a disinfection sequence on machine 90.

[0164] In one embodiment, when the self-test button 240a is selected, any machines 90a-90n that are available to perform a self-test at that time have their corresponding icons 190a-190n highlighted. The nurse, clinician, or doctor 112 selects any icon 190 associated with the machine 90 on which the nurse, clinician, or doctor 112 wishes to perform a self-test. That selected icon 190 may then change to a "Confirm" button that the nurse, clinician, or doctor 112 must press again to have the selected machine 90 perform the self-test. The app 230 of the mobile communication device 200 then sends the corresponding self-test code to middleware software at the system hub 120 or local system hub 220, which converts the self-test code, if necessary, into a start self-test command, which is sent to the connection agent 114 of the selected machine 90 via a securely managed connection 116 via the connection server 118, which forwards the command to the machine's ACPU 50, which in turn initiates the self-test.

[0165] In the illustrated embodiment, when the disinfect button 240b is selected, any machines 90a-90n capable of performing disinfection at that time have their corresponding icons 190a-190n highlighted. The nurse, clinician, or doctor 112 selects any icon 190 associated with the machine 90 on which the nurse, clinician, or doctor 112 wishes to perform disinfection. The selected icon 190 may then change into a “Confirm” button that the nurse, clinician, or doctor 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 at the system hub 120 or local system hub 220, which converts the disinfection code into a start disinfection command, if necessary, and sends the command to the connectivity agent 114 of the selected machine 90 via the securely managed connection 116 via the connectivity server 118. The agent 114 forwards the command to the machine's ACPU 50, which, in turn, begins disinfection.

[0166] The procedures thus described for action button 240 may also be implemented in system 110c for other machine commands, which may vary depending on the type of machine 90. It is also envisioned that clinic 126a may determine, via one or more nurses, clinicians, or doctors 112 present at the clinic, that it is sufficiently safe to leave connectivity agent 114 on during a treatment or portion of a treatment. In such a case, the nurses, clinicians, or doctors 112 may control in-treatment activities related to machine 90. For example, the nurses, clinicians, or doctors 112 may receive and respond to alarms / alerts via app 230 on mobile connected device 200, start and stop pumps and other aspects of treatment, start and stop disinfection, start and stop priming, etc.

[0167] Each of the systems 110a-110d operates using some form of addressing scheme. As discussed above, the connection server 118, in one embodiment, is provided to ensure that data is delivered to the appropriate machine 90 in the appropriate form and that data from the machine 90 is delivered to the appropriate destination in the appropriate form. In one embodiment, when a 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 keeps track of each mobile communication device 200 to which a particular machine's data 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, a machine identifier may be delivered, for example, with the converted data so that app 230 knows which icons 190a-190n to populate with the new data, where 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 a 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 the local system hub 220 may or may not translate 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. The connection server 118 knows, for each mobile communication device 200, which machine 90 should receive the translated data, for example, and transmits the translated data to each associated communication device 200, for example. The connection server 118 may remove the mobile communication device 200 identifier from the data once it is delivered to the machine 90, as it is no longer needed.

[0169] The app 230, as described above, allows a nurse, clinician, or physician 112 to configure, monitor, and possibly control treatment on the medical fluid delivery machine 90. It is envisioned that similar functionality may be provided via an app to a patient 12 or a caregiver for the patient 12 in the patient's home (dashed box in FIG. 1 ). The connectivity may be identical to that shown in FIGS. 7-9 . However, the setting is not a clinic 126 a-126 n, but instead a home or other non-clinical location, such as a business or vacation location. Additionally, typically, there is only a single machine 90, rather than multiple machines 90 a-90 n. 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 the patient 12 is at home but away from the machine 90, the app may provide useful information, such as the amount of time remaining to initiate or complete startup procedure tasks, disinfection procedures, or self-test routines. As the patient is being treated by the machine 90, the patient can view information on its user interface 122, which itself may be a tablet as illustrated in FIG. 1. However, there may also be a caregiver, such as a spouse, friend, or home nurse, assisting the patient 12 at home during treatment. The caregiver benefits from the home app by receiving status updates, time remaining for the start-up procedure, time remaining for disinfection, time remaining for priming, time remaining for treatment, information regarding whether the patient 12 is connected to the machine 90, alerts, alarms, etc. The app in one embodiment requires that a login and password associated with the patient be entered before it can be downloaded to the caregiver's mobile communication device 200, so that only authorized personnel can view patient treatment data or information.

[0170] II. PATIENT ENGAGEMENT EMBODIMENTS The exemplary medical fluid delivery data transfer system 10 disclosed above in connection with Figures 1-9 is configured to improve patient engagement with medical fluid delivery therapies, such as dialysis therapy, renal failure therapy, 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 connection with Figures 1-9 , according to certain exemplary embodiments of the present disclosure. The exemplary medical fluid data transfer system 1000 (e.g., a mobile platform) is configured to improve patient engagement and / or compliance with therapy by providing features for controlling and reporting therapy-related information to patients that increase therapy transparency and / or provide access to educational materials and / or real-time assistance from clinicians.

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

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

[0173] Peritoneal dialysis fluids may include solutions or mixtures containing 0.5% to 10%, preferably 1.5% to 4.25%, of dextrose (or more generally, glucose). Peritoneal dialysis fluids may include, for example, Dianeal®, Physioneal®, Nutrineal®, and Extraneal® dialysates, commercially available from the assignee of the present disclosure. Additionally or alternatively, the dialysate may include a percentage of icodextrin.

[0174] In both hemodialysis and peritoneal dialysis, "sorbent" technology can be used to remove uremic toxins from waste dialysate, reinfuse therapeutic agents (such as ions and / or glucose) into the treated fluid, and reuse the fluid to continue dialysis of the patient. One commonly used sorbent is made from zirconium phosphate, which is used to remove ammonia generated from the hydrolysis of urea. Typically, large amounts of sorbent material are required to remove the ammonia generated during dialysis treatment.

[0175] Exemplary weighing scales 106 include any device configured to measure the mass of a patient or a therapy component. For example, the weighing scale 106 may measure the patient's weight before, during, and / or after a renal failure therapy treatment. Additionally or alternatively, the weighing scale 106 may weigh a supply or drain bag to track renal failure therapy. Specifically, the weighing scale 106 may be used to measure the amount of UF removed or the amount of fluid provided to the patient. The weighing scale 106 may display a digital value indicating weight. Alternatively, the weighing scale 106 may display a physical scale or dial aligned with a marker to indicate the measured weight. In some embodiments, the weighing scale 106 may store weight values ​​before, during, and / or after treatment in a separate window so that patient input is required to view all values ​​when medical information is recorded.

[0176] The exemplary blood pressure monitor 104 includes any device configured to measure a patient's blood pressure and / or pulse. For example, the blood pressure monitor 104 may measure the patient's blood pressure before, during, and / or after a renal failure therapy treatment. The blood pressure monitor 104 may display a digital value indicating the patient's blood pressure. Alternatively, the blood pressure monitor 104 may display a physical scale with a dial aligned with a numerical value to indicate the measured blood pressure. In some embodiments, the blood pressure monitor 104 may store blood pressure values ​​before, during, and / or after treatment in a separate window so that patient input is required to view all values ​​when medical information is recorded. The blood pressure monitor 104 may be integrated with the 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 the medical devices 90, 104, and 106, the exemplary personal mobile communication device 200a may also obtain medical information from patient and / or therapy consumable items 1006. FIG. 10 shows examples of consumable items 1006 including, for example, a renal failure therapy medical device filter, a disposable cassette, a blood line set, a drug delivery line set, and a container (e.g., a dialysate concentrate container, a blood anticoagulant container, a medicine container, and / or a purified water container). The consumable items 1006 may also include sorbent cartridges or any other disposable or substance source for medical treatment. The consumable items may include an identifier 1008 configured to provide medical information in the form of consumable information or consumable data. For example, the identifier 1008 may include information identifying the type of consumable item, a serial number, and / or characteristics of the consumable item. In some cases, the consumable item 1006 may also include an indicia containing medical information, such as chemical composition characteristics. The patient or clinician uses the personal mobile communication device 200a to record an image of the identifier 1008, an image of the label on the consumable item 1006, and / or an image of the 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 scale 106 via a wired connection (e.g., a USB connection) or a wireless connection (e.g., Bluetooth, WiFi, Zigbee, Z-Wave, wireless USB, or a wireless local area network (“WLAN”)). In other examples, the personal mobile communication device 200a is not communicatively coupled to any one of the home therapy machine 90, the blood pressure monitor 104, and / or the scale 106. In these other examples, the patient may manually enter data displayed by the home therapy machine 90, the blood pressure monitor 104, and / or the scale 106 into the personal mobile communication device 200a. Additionally or alternatively, in these other examples, the patient may use the camera 1004 of the personal mobile communication device 200a to record one or more images of the data displayed by (or identifiers placed thereon with) the home therapy machine 90, the blood pressure monitor 104, and / or the scale 106.

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

[0180] In some embodiments, the personal mobile communication device 200a is configured to record, display, and / or populate a patient medical record with medical information or data. As disclosed herein, medical information or data includes medical device data and patient data, which may refer to data or information created by, generated by, or otherwise related to a medical device, a patient, and / or consumable items used by the medical device. For example, medical information includes prescription or programming information used by a medical device to administer a 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 patient physiological information such as a patient's blood pressure, weight, heart rate, etc. Medical information may also include subjective information, such as information regarding a patient's mood (e.g., bored, fatigued, happy, excited, etc.). Medical information can be displayed on a screen of a medical device, provided by a physical dial or display of a medical device, or printed on an attached sign or medical device. Thus, 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 an identifier attached to a patient or a treatment consumable item. Specifically, medical information may include information conveyed by a patient identifier provided on a patient's wristband to identify the patient. Medical information also includes information about the consumable item, which may identify the consumable item type, consumable item model, and / or characteristics of the consumable item, such as the level of glucose in a supply bag of renal failure therapy solution.

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

[0183] As shown in FIG. 10 , some of the medical devices 90, 104, and 106 may include an identifier 1012 configured to store a unique identification number. The identifier 1012 may encode, for example, 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, for example, to determine the medical device type for subsequent analysis and the identification of 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 the device 106 is a weighing scale and / or indicate the model number of the weighing scale.

[0184] The identifier 1012 may include machine-readable markings such as, for example, a barcode or a quick response (“QR”) code. The identifier 1012 may also include human-readable text such as a serial number, asset number, or hardware number. In some embodiments, the identifier 1012 may be printed on an item physically attached to the housing of the respective medical device 90, 104, and 106, such as identifier 1012b shown for home therapy machine 90. Additionally or alternatively, the 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 the home therapy machine 90 to display a window with the identifier 1012b on the screen. In still other embodiments, the 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 instructions. For example, the home therapy machine 90 includes a control interface 1014. The control interface may include buttons, a control panel, or a touch screen. The control interface may be configured to allow a user to navigate to certain windows or user interfaces on the screen of the respective medical device 90, 104, and 106. The control interface may also provide instructions for operating or controlling the respective medical device 90, 104, and 106.

[0186] As illustrated in FIG. 10 , an exemplary fluid data transfer system 1000 includes a web portal 150, a system hub 120, and a clinician server 200b (similar to the respective devices discussed in connection with FIGS. 1-9 ) for communicating with a personal mobile communication device 200a. The web portal 150, the system hub 120, and / or the clinician server 200b transmit medical information from a patient's medical record (stored in a clinician database 1010) to the personal mobile communication device 200a. In addition, the web portal 150, the system hub 120, and / or the 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, the system hub 120, and / or the clinician server 200b are also configured to enable the personal mobile communication device 200a to provide medical information for entry into the patient's medical record.

[0187] 10 also includes a connectivity server 118 that is communicatively coupled to the home therapy machine 90. As discussed above in connection with FIGS. 1-9 , the connectivity 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 connectivity server 118 via the Internet.

[0188] 10 , the exemplary personal mobile communications device 200a includes a processor 1016 in communication with a memory 1018 that stores instructions. At least some of the instructions define or prescribe applications 1002 that, when executed by the processor 1016, cause the processor 1016 to provide features that improve patient engagement and / or compliance with treatment. The processor 1016 may comprise digital and analog circuitry structured as a microprocessor, an application specific integrated circuit (“ASIC”), a controller, or the like. The memory 1018 includes a volatile or non-volatile storage medium. Additionally, the memory 1018 may include any solid-state or disk storage medium.

[0189] As discussed in more detail below, features of the application 1002 include displaying treatment progress information, controlling treatment programs launched by the home therapy machine 90, recording medical information, displaying educational materials, and / or initiating a help session with a clinician. The application 1002 may be feature-rich or feature-less. A feature-rich application is configured for a smartphone and takes advantage of the inherent graphics, touchscreen, and processing capabilities of the personal mobile communications device 200a. A feature-less application is configured to run on a cellular phone with relatively less sophisticated graphics and reduced processing power. The cellular phone may not include a touchscreen or, instead, may have a touchscreen with limited capabilities.

[0190] In some embodiments, the personal mobile communication device 200a may not include the application 1002. Instead, the personal mobile communication device 200a may use a native application or other installed applications 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 an application 1020, such as the application 230 described in connection with Figures 1-9. The application 1020 is configured to communicate with the personal mobile communication device 200a and provide improved patient engagement and / or compliance. In some embodiments, the exemplary application 1020 is configured to facilitate storage of medical information (recorded by the personal mobile communication device 200a) in one or more patient records in the database 1010. The application 1020 may also include one or more interfaces or application programming interfaces ("APIs") to provide treatment progress data and / or medical information to the application 1002 for display on a display interface 1022 (e.g., a touchscreen) on the personal mobile communication device 200a. The application 1020 on the clinician server 200b may provide educational materials and / or facilitate communication sessions between the personal mobile communication device 200a and the clinician device 152 in response to requests from the application 1002.

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

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

[0194] The 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 personal mobile communication device 200a. In addition, the application 1020 may include a data access module 1106 for transmitting or otherwise providing access to medical information stored in one or more patient records associated with the patient. The application 1020 may further include an education module 1108 configured to provide access to educational materials or help documents for the patient regarding their treatment and / or the operation of the home therapy machine 90. Furthermore, the application 1020 may include a therapy control module 1110 that enables the patient (or clinician) to change (or modify) the therapy program implemented by the home therapy machine 90. The application 1020 may additionally include an auxiliary module 1112 that creates a real-time communication session between the personal mobile communication device 200a and the clinician device 152.

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

[0196] As discussed below, each of the modules 1102-1112 is configured to communicate with the personal mobile communication device 200a and / or the clinician device 152. In some embodiments, communications from the personal mobile communication device 200a may be addressed generally to the clinician server 200b, the web portal 150, the connectivity server 118, and / or the system hub 120. Messages may be routed internally to different modules 1102-1112 based on content and / or identifier. For example, the application 1002 may provide an identifier in a header to specify which module 1102-1112 should receive the message. For text-based messages, a router in the 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 the data acquisition module 1104. Based on this correspondence, the router sends the received message for processing via the data acquisition module 1104.

[0197] A. Registration Module Embodiments The example registration module 1102 is configured to register the personal mobile communications device 200a and / or home therapy machine 90 with the clinician server 200b and / or with the patient's medical record stored in the database 1010. The example registration module 1102 is configured to provide different types of registration, which is used by the data access module 1106 to determine how information should be displayed to the patient based on the type of device being registered. Additionally, the data acquisition module 1104 determines how treatment and / or medical information should be acquired based on the registration information.

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

[0199] In some embodiments, different registration scenarios exist. For example, a patient may register the home therapy machine 90 while registering the personal mobile communication device 200a by downloading the application 1002. In this scenario, the registration module 1102 records that the patient installed the application 1002 on the personal mobile communication device 200a and registered the home therapy machine 90 (either separately or through the application 1002). Based on this registration, the data acquisition module 1104 determines that the 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 treatment information should be received from the home therapy machine 90, rather than via the personal mobile communication device 200a. In response, the data acquisition module 1104 may send a message to the application 1002 to disable the user interface to obtain treatment information from the home therapy machine 90 (but still enable the user interface for manual replacement, if a manual replacement is prescribed for the patient). If the home therapy machine 90 is not registered, the data acquisition module 1104 causes the application 1002 to display a user interface for acquiring therapy information from the home therapy machine 90 in the application 1002. Through registration, the data access module 1106 determines that information should be displayed through the application 1002 and accordingly uses APIs and / or other data retrieval components compatible with or configured for the application 1002.

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

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

[0202] FIG. 12 shows a diagram illustrating communication between the home therapy machine 90 of FIGS. 10 and 11, the personal mobile communications device 200a, and the clinician server 200b, in accordance with certain exemplary embodiments of the present disclosure. Initially, the home therapy machine 90 is registered with the clinician server 200b via the registration module 1102 of FIG. 11. Otherwise, the clinician server 200b would not have information regarding 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 regarding the connectivity server 118, the system hub 120, and / or the clinician server 200b. The destination address may include an Internet Protocol (“IP”) address and / or a Hypertext Transfer (or Transport) Protocol (“HTTP”) address.

[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 at 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 code unique to the patient. A registration module 1102 at the clinician server 200b stores the generated PAC in one or more patient records and / or registration files associated with the patient. After entering the PAC, the home therapy machine 90 generates and transmits a message 1202 containing the PAC. The message may also include a hardware identifier for the home therapy machine 90 and / or an IP address assigned to the home therapy machine 90. The home therapy machine 90 transmits the message 1202 to a preprogrammed address, in this case, the connectivity server 118. The exemplary connectivity server 118 relays the message 1202 to the system hub 120, which routes the message to the clinician server 200b. A registration module 1102 in the clinician server 200b uses the PAC to register the home therapy machine 90 with the patient. Registration may include, for example, associating an identifier for the home therapy machine 90 with the patient's patient medical record. Registration may also include the clinician server 200b storing the IP address of the home therapy machine 90 to enable messages to be transmitted to the home therapy machine 90. After registration, a data acquisition module 1104 in the clinician server 200b stores the treatment information received from the home therapy machine 90 in one or more medical records associated with the patient.

[0204] The exemplary personal mobile communication device 200a is also configured to be registered 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 some embodiments, during registration of the home therapy machine 90, the patient (or clinician) may provide a phone number for the personal mobile communication device 200a. The registration module 1102 uses the phone number and transmits the message 1204 as a text message. The message may include a hyperlink to a location (e.g., the database 1010 or a third-party website) that provides the application 1002 for download to the personal mobile communication device 200a. In other cases, the message 1204 may include an attachment that, when executed, installs the application 1002 on the personal mobile communication device 200a. Instead of providing a phone number, the patient may instead provide an email address during registration of the home therapy machine 90. Thus, the message 1204 comprises an email message with a file or hyperlink for installing the application 1002 on the personal mobile communication device 200a.

[0205] In another embodiment, message 1204 may allow the patient to register two different ways, depending on the capabilities of their personal mobile communication device 200a and / or personal preferences. Message 1204 includes text prompting the patient to respond to the text if they wish to register their personal mobile communication device 200a as a reduced-feature device. A reply to message 1204 is provided via text message 1206, which is routed to registration module 1102. Registration module 1102, in turn, registers personal mobile communication device 200a with instructions that application 1002 is not installed. In some instances, message 1204 may also include text or a hyperlink prompting the patient to select or otherwise obtain application 1002, if desired. 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] The patient may register the personal mobile communication device 200a after the application 1002 is installed. In one embodiment, to register, the patient completes a registration form or fields provided by the 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, phone number, etc. Information from the form or fields is sent in one or more messages 1206 to the web portal 150, 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 for the personal mobile communication device 200a (as determined by the application 1002).

[0207] In some cases, the application 1002 may be configured with a destination address of the web portal 150, which is used to transmit the message. In other cases, the message 1206 may be provided to an API in the web portal 150 to register the application 1002 on the clinician server 200b. In still other cases, the application 1002 transmits the message 1206 as one or more text or email messages to the web portal 150 (the web portal 150 has been assigned a phone number, IP address, email address, or other address). The example registration module 1102 uses the PAC in the message 1206 to register the personal mobile communication device 200a in a medical record and / or registration file stored in the database 1010. At this point, both the home therapy machine 90 and the personal mobile communication device 200a are registered to the same patient on 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 with their PAC. Providing a PAC via any of these registration processes allows the registration module 1102 to associate the personal mobile communication device 200a (e.g., phone number, hardware address, or IP address) with the appropriate patient medical record and / or registration file.

[0209] B. Data Acquisition Module Embodiments FIG. 12 also illustrates data communication between the home therapy machine 90, the personal mobile communications device 200a, and the clinician server 200b. During operation, the home therapy machine 90 generates treatment and status information (e.g., medical information). As discussed above in connection with FIGS. 1-9, treatment information includes the volume of fluid infused, 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 the medical information, which are transmitted to the connectivity server 118. The connectivity server 118, in turn, 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. Upon receipt, the data acquisition module 1104 stores the medical information in a designated section of the patient's medical record (e.g., the patient medical record 1302 of FIG. 13). The message 1208 may include an identifier or address of the home therapy machine 90 , which is used by the data acquisition module 1104 to locate the appropriate medical record in the database 1010 .

[0210] The exemplary home therapy machine 90 may be configured to code, label, or otherwise identify the medical information being transmitted using metadata or other data identification techniques. The coding or labeling allows the data acquisition module 1104 (or an interface in the server 200b) to determine the context of the medical information for writing the medical information into the appropriate fields of the patient record. Additionally or alternatively, the coding or labeling may be stored in the record for later use in retrieving and displaying the medical information.

[0211] FIG. 12 illustrates a personal mobile communication device 200a transmitting medical information to a clinician server 200b. As described in more detail below, the personal mobile communication device 200a is configured to acquire medical information from medical devices, including devices 90, 104, and 106. Acquiring the 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 acquired 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, Extensible Markup Language (“XML”) messages, JavaScript Object Notation (“JSON”) payloads, etc.). In some embodiments, the personal mobile communication device 200a may format the acquired medical information into one or more data fields prior to transmission. Generally, the medical information acquired at the personal mobile communication device 200a is less structured than the medical information generated by the home therapy machine 90. Thus, the data acquisition module of the personal mobile communication device 200a and / or the clinician server 200b performs at least some processing of the medical information to provide the appropriate context or structure for inclusion within the patient medical record. Examples of the processing performed are described in more detail below.

[0212] 13 illustrates an exemplary patient data structure 1300 stored on the clinician database 1010 of FIG. 10 , in accordance with 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 the identifier “DCM31913” and a patient medical record 1304 for a patient associated with the identifier “GAM41215.” The data structure 1300 may include additional patient medical records.

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

[0214] 13 , medical records 1302 and 1304 include fields related to treatment and medical information. Data acquisition module 1104 stores treatment information received from each home therapy machine 90 in records 1302 and 1304. In addition, data acquisition module 1104 stores medical information received from each personal mobile communications device 200a in records 1302 and 1304. In some embodiments, the data fields are further divided into individual fields related to data type. For example, records 1302 and 1304 may include treatment information fields related to the volume of fluid infused, the amount of ultrafiltration (“UF”) removed from the patient, and / or the duration of treatment. Records 1302 and 1304 may also include data fields related to alerts or alarms generated during treatment and / or alarms or alerts determined in clinician server 200b based on the treatment information 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] The treatments and / or medical devices may be organized by treatment, date / time generated, and / or date / time received. In some embodiments, the medical records 1302 and 1304 may store communications from the patient. The communications may include photos or videos recorded by the personal mobile communication device 200a related to the treatment or questions about the treatment. The communications may also include text messages, emails, etc. regarding treatment assistance sent from the personal mobile communication device 200a. Additionally, the 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. Generally, the medical records 1302 and 1304 are configured to store information for improving the patient's engagement in the treatment, in addition to documenting the results of the treatment and information related to the patient's engagement with the clinician server 200b regarding the treatment.

[0216] The data received by the exemplary data acquisition module 1104 varies based 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 formatted for direct entry into one or more data fields of the patient's medical record. In some embodiments, the home therapy machine 90 formats a message for transmission through the API of the data acquisition module 1104 (or otherwise accesses one or more APIs) for entry of the treatment information into the appropriate data fields. In contrast, medical information recorded by the patient's personal mobile communication device 200a may not initially be structured for inclusion in the patient's medical record. As described in more detail below, different techniques may be used by the application 1002 of the personal mobile communication device 200a and / or the data acquisition module 1104 of the clinician server 200b to process and / or format the medical information for entry into the medical record.

[0217] 1. Manual Input of Medical Information into the Application To receive the structured information, the example application 1002 of the personal mobile communication device 200a, in some embodiments, is configured to display a prompt indicating medical information required for entry by the patient into the patient's medical record. The example application 1002 may include a routine or algorithm that defines 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 relative to the medical fluid delivery treatment. The display of the fields informs the patient as to the medical information required for the patient's record.

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

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

[0220] After receiving medical information manually entered by the patient, the example 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 so that the data fields for receiving the 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 into designated data fields in the patient's medical record. The application's user interfaces 1400 and 1500 thus prompt the patient for the medical information in a structured manner such that identification or formatting of the medical information is not required or necessary.

[0221] In some embodiments, the application 1002 may be configured to display the user interfaces 1400 and 1500 at a designated time. For example, the application 1002 may include a calendar including the time / day for which treatment is scheduled. At a designated time (e.g., 5 minutes, 15 minutes, 30 minutes, etc.) before treatment, the example application 1002 is configured to cause the personal mobile communications device 200a to display the user interface 1400 and prompt the patient regarding blood pressure medical information. The prompt informs the patient that a blood pressure measurement is required before treatment can begin. The patient accordingly uses the blood pressure monitor 104 to take the blood pressure measurement. The patient then enters the value of the measurement into the user interface 1400 before treatment begins.

[0222] In the illustrated embodiment, user interface 1400 includes a systolic blood pressure data field 1402, a diastolic blood pressure data field 1404, and a pulse data field 1406. The patient may select the respective data field 1402, 1404, or 1406 to cause application 1002 to display a text entry feature for entering a value. 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. Additionally, 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 examples, the patient may select any one of fields 1402-1410 to receive further information about performing the corresponding measurement. For example, the patient may select systolic blood pressure data field 1402, which causes application 1002 to display a tutorial instructing the patient how to perform a blood pressure measurement and identify the systolic blood pressure reading. The tutorial may include text, text / photos, audio recording, animation, and / or video. The tutorial may be stored locally as part of application 1002 or stored on clinician server 200b for remote access or streaming.

[0224] 15 is configured to be displayed by application 1002 when a patient is scheduled to perform a manual exchange therapy and / or when home therapy machine 90 is not registered with clinician server 200b. Manual renal failure exchange therapy requires the patient to connect a container of dialysis fluid to their peritoneal cavity for a dwell time before allowing the spent dialysis fluid to drain, all without the assistance of a machine. For manual therapy, patients are required to enter their manual exchange medical information to enable their records to reflect accurate therapy information.

[0225] The example application 1002 may also be configured to display the user interface 1500 when the patient has not registered the home therapy machine 90. During registration, the registration module 1102 may transmit a message to the application 1002 indicating whether the home therapy machine 90 is registered. If the home therapy machine is not registered, the 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 machine 90.

[0226] In the illustrated example, user interface 1500 includes a progression through therapy including a solution phase, a drain phase, a fill phase, a UF or dwell phase, and an explanation phase. The application 1002 may display a separate user interface for each phase, prompting the patient to enter corresponding or requested therapy information. The exemplary user interface 1500 corresponds to the UF phase, as indicated by the highlighted box 1502. User interface 1500 includes a drain volume field 1504, a UF field 1506, and a fill volume field 1508. In the illustrated example, user interface 1500 prompts the patient to enter a drain volume in data field 1504 during the drain phase and a fill volume in data field 1508 during the fill phase. User interface 1500 may calculate a UF value for UF data field 1506 or prompt the patient for a value.

[0227] Instead of displaying user interfaces 1400 and 1500 at the designated time, application 1002 may instead cause an alarm to be displayed on personal mobile communication device 200a. The alarm may identify the needed medical information or include a link to either user interface 1400 or 1500. The alarm may include a pop-up window displayed by personal mobile communication device 200a. The alarm may also include an icon displayed adjacent to an icon for application 1002 on the home screen of personal mobile communication device 200a. In yet other embodiments, application 1002 may not notify the patient of the needed 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, the application 1002 may identify at least some of the data fields of one or more user interfaces as required for input, while other data fields are optional for input. The application 1002 may outline or otherwise graphically indicate required data fields (e.g., displaying a red border around the systolic blood pressure data field 1402). The application 1002 may cause an alert message to be displayed by the personal mobile communications device 200a if a required data field is not completed or is not completed by a certain time. In some embodiments, the application 1002 may prevent the patient from navigating to another user interface until all required fields are populated with data for the currently viewed user interface.

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

[0230] 2. Wireless Input of Medical Information into an Application In some embodiments, the patient may choose to input medical information wirelessly on their personal mobile communication device 200a. The medical information may be received at the personal mobile communication device 200a via, for example, a Bluetooth® connection, a Zigbee® connection, a Z-Wave® connection, a wireless USB connection, a wireless RF connection, an NFC connection, an infrared connection, or any other suitable wireless communication technology. In some cases, the patient may need to wirelessly pair the personal mobile communication device 200a with a medical device such as a blood pressure monitor 104 and / or a scale 106. In other embodiments, the patient activates a connectivity application (e.g., an NFC application) that wirelessly reads the 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 enter blood pressure medical information into the user interface 1400 of FIG. 14, the user selects, for example, the systolic blood pressure data field 1402. Selection of field 1402 causes the application 1002 to display a prompt asking the patient to select a data entry method (e.g., manual, wireless, photo, etc.). After selecting the wireless option, the application 1002 displays a menu of available wireless connection options and / or a list of paired Bluetooth devices. The patient selects the blood pressure monitor 104 from the list, which causes a menu of available medical information to be displayed. The patient selects systolic blood pressure, which causes the systolic blood pressure value to be populated into the systolic blood pressure data field 1402. In some embodiments, the application 1002 is configured to read medical information from the blood pressure monitor 104 after the device is selected by the patient. The application 1002 may use the data indicators or metadata to determine which fields 1402 - 1410 should be populated with medical information from the blood pressure monitor 104 .

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

[0233] (3. Embodiment of image input of medical information into application) An example application 1002 on a personal mobile communication device 200a is configured to allow a patient to enter 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. The application 1002 uses optical character recognition ("OCR") to extract text from the recorded images. The extracted text is populated into one or more data fields in the user interface of the application 1002. The use of images may reduce data entry errors from the patient or clinician.

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

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

[0236] The data template defines or prescribes data fields for certain medical information contained within the image. Typically, the image includes extracted text comprising the medical information. In some cases, not all of the extracted medical information is needed or required. Instead, only certain medical information within the recorded image is required for entry 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 entry into data fields in the user interface of application 1002, or more generally, for entry into the patient's medical record.

[0237] 16 illustrates a schematic diagram of a personal mobile communication device 200a for recording and processing images for medical information extraction, according to certain example embodiments 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 that, when executed by the data processor 1602 (or more generally, the processor 1016), cause the application 1002 to process images to extract medical information.

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

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

[0240] In other embodiments, the data processor 1602 may guide the patient through one or more steps to obtain an image. The data processor 1602 may execute a workflow or routine based on the data fields selected by the patient. For example, the data processor 1602 executes a blood pressure workflow to acquire an image 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 of FIG. 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. Additionally, the data processor 1602 may display a reminder message if an image is not recorded within a predetermined period (e.g., five 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 control interface of the medical device. The message may further include graphical elements, such as an exemplary depiction of the medical device, consumable item, identifier 1012, and / or user interface window where 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 the 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 the medical information using one or more data templates or data indicators to determine the extracted medical information to be populated or written into data fields in the user interface or medical record.

[0243] To record an image, the exemplary data processor 1602 and image processor 1604 (more generally, processor 1016) provide operation for the application 1002 associated with the camera 1004. The patient provides instructions via the camera user interface 1606 (e.g., a touchscreen or buttons on the personal mobile communications device 200a) to record an image. The patient activates the camera user interface 1606, for example, when the camera is focused on a medical device user interface window or identifier 1012. The data processor 1602 receives the instructions and instructs the camera 1004 to record an image. The recorded image is transmitted from the camera 1004 to the image processor 1604. Additionally, a copy of the image is displayed by the data processor 1602 on the display interface 1022 of the personal mobile communications device 200a.

[0244] In some embodiments, the data processor 1602 may cause a residual image to appear on the display interface 1022, illustrating the image to be recorded. The residual image is provided over the stream of images provided by the camera 1004 in preview mode. The purpose of the residual image is to provide an aid to the clinician or patient to verify that the image to be recorded contains the desired medical information and is being recorded at the appropriate distance. For example, the data processor 1602 may display a residual 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 the identifier 1012a is positionally aligned with the residual image. The patient may then record an image of the identifier 1012a. In some instances, the data processor 1602 uses image analysis to determine differences between the residual image and the stream of images. The data processor 1602 may cause instructions to be displayed 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 is below a certain threshold and indicate that the images are aligned. Once the images are substantially aligned, the data processor 1602 may provide a graphical indication on the display interface 1022 that the image may be recorded, or may cause the image to be recorded automatically without input from the patient.

[0245] The data processor 1602 may provide a prompt asking the patient to accept the image. After receiving an instruction to accept 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. The image processor 1604 continues to perform the analysis to identify text until the image is deleted.

[0246] To identify text, the image processor 1604 may use, for example, OCR. Additionally, 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 in the image file of the image as metadata. The image processor 1604 may also use the clock of the personal mobile communication device 200a to attach a date / time (corresponding to the time when 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 identify patients, medical devices, and / or consumable items using image analysis. For example, the image processor 1604 may access a library of medical device images to identify medical devices within the images. In this example, the image processor 1604 may use an image matching routine to determine a match. Such a comparison may be made on behalf of the medical device with the identifier 1012. The image processor 1604 may use similar routines and / or algorithms to identify the consumable item 1006.

[0248] The example data processor 1602 is configured to decode the identifier 1012 and determine the medical device type of the consumable item. The decoding may include correlating the position and thickness of the lines and / or rectangles to associated medical information. The coded lines and rectangles may correspond to a series of letters and / or numbers. For example, the data processor 1602 may use the lines or rectangles of the identifier 1012 to determine a device model number, a medical device type, an asset code, etc. The decoded identifier 1012 may provide the associated medical information for populating one or more data fields of the user interface of the application 1002. Additionally or alternatively, the decoded identifier may be used by the data processor 1602 to select a workflow for obtaining images from the medical device or consumable and / or to determine a data template.

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

[0250] FIG. 17 illustrates a schematic diagram of a data template 1700, according to an example embodiment of the present disclosure. The example data template 1700 is used by the 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 within a data field in the user interface of application 1002. Other pieces of data may be less relevant or irrelevant. Furthermore, depending on the model of the medical device, the medical information may be in different locations or have different labels. The data template 1700 is configured to specify the location and name of relevant medical information for a particular home therapy machine 90.

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

[0252] The example data template 1700 of FIG. 17 includes device data (or text) fields 1702, 1704, 1706, and 1708, which define where certain medical information will be located on a particular user interface window of a medical device. In some examples, the data template 1700 is graphical, whereby image analysis is performed to align the fields 1702-1708 with extracted text in the image. In other examples, the data template 1700 includes a file (or other data structure) having coordinates or locations for 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 locations 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 sign text in addition to coordinates and / or location. For example, device data field 1702 includes sign text "Ultrafiltration window," while device data field 1704a includes sign text "UF volume." Image processor 1604 matches sign text to similar text extracted from images. In some instances, matches between sign text are used exclusively to identify device data fields rather than using location or image analysis.

[0254] A match between sign text, including sign text for unrelated device data fields, can be used to confirm that the image is from the correct window or screen of the medical device. For example, the image processor 1604 may match the sign text "ultrafiltration window" to corresponding extracted text in the relatively same location on the recorded image. The match confirms that the image was recorded from the ultrafiltration window of the renal failure therapy medical device. However, the extracted text is not relevant medical information for the patient's medical record. If the sign 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] The indicator text associated with device data fields 1706 and 1708 may be used to verify that the recorded image is current or has been recorded within a predetermined time period. For example, some windows on medical devices display the current date and time. This information may be extracted by image processor 1604 and identified using device data fields 1706 and 1708. Image processor 1604 compares the extracted date / time with date / time rules or limits associated with device data fields 1706-1708 to determine if the recorded image is current. For example, image processor 1604 may determine that another image is required to be recorded if the date does not match or if the time is not within a predetermined threshold (e.g., 5 minutes, 15 minutes, 60 minutes, 3 hours, etc.) of the current time on personal mobile communications device 200a.

[0256] The example device data fields 1704a and 1704b of FIG. 17 are used by the application 1002 to identify relevant medical information. In some instances, the application 1002 may display a flag or metadata indicating that the device data fields 1704a and 1704b are associated with a selected data field of a user interface (e.g., user interface 1400 or 1500). In comparison, the device data fields 1702, 1706, and 1708 may include a flag or metadata indicating that the corresponding extracted data is not associated. In the example illustrated in FIG. 17, the image processor 1604 uses the indicator text of the data field 1704a to locate the corresponding extracted text within the image. The image processor 1604 then uses the positional relationship between the device data fields 1704a and 1704b, or the text value markers, to identify the extracted medical information from the image that corresponds to the numerical value of the ultrafiltration volume. The image processor 1604 copies the extracted medical information associated with field 1704b from the image to populate, for example, the systolic blood pressure data field 1402 of FIG.

[0257] As discussed above in connection with FIG. 17 , the data processor 1602 of FIG. 16 may use known positional relationships of text and text markers within an image to determine extracted text that corresponds 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 the identifier 1012, received from the patient via the camera user interface 1606, and / or specified through the selection of a data field in a user interface for the application 1002 into which the medical information should be entered. In other examples, the data processor 1602 compares the data templates in the database 1608 to the image with the extracted text to find a match. In these other examples, the data processor 1602 uses the position of the text markers and the text between the image and the data template to determine the match.

[0258] After identifying the relevant medical information, the example data processor 1602 is configured to write or otherwise populate one or more data fields of the user interface of the application 1002 with the relevant medical information. In some embodiments, the data processor 1602 is configured to automatically populate the data fields of the user interface of the application 1002 using a data template. To automatically populate the medical information, the data processor 1602 compares text, indicators, and / or metadata associated with fields of the data template with text, indicators, metadata, and / or other data field information of one or more user interfaces of the application 1002. If at least some of the text, indicators, and / or metadata match, the data processor 1602 identifies certain text (e.g., numeric values) that correspond to the matching fields of the data template. The identified text is written to the corresponding matching data fields of the user interface of the application 1002.

[0259] In other embodiments, the data processor 1602 is configured to prompt the patient to select one or more fields of a data template and enter data into one or more data fields of the user interface of the application 1002. FIG. 18 shows a diagram illustrating a patient entering data into data fields 1402-1406 of the user interface 1400, according to an exemplary embodiment of the present disclosure. In the illustrated example, the user interface 1400 is opened on the personal mobile communication device 200a. To enter medical information into the data fields 1402-1406, the patient selects each of the data fields sequentially or together. With each selection, the application 1002 displays a prompt asking the patient how the data should be entered. After the patient selects a photo entry method, the application 1002 opens a camera application, allowing the patient to record an image 1800 of the screen of the blood pressure monitor 104 using the personal mobile communication device 200a. In some embodiments, the 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 that corresponds to the extracted text. In some embodiments, the application 1002 matches the location of text and / or signs in the image to the text and / or signs in the data template to find a matching data template. In another example, the patient may specify instructions for the blood pressure monitor 104, which allows the application 1002 to find the corresponding data template 1801. In yet another example, the application 1002 may first prompt the patient to record an image of the blood pressure monitor 104's identifier 1012a. 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 involves 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 spacing between characters and / or words.

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

[0262] In some embodiments, the application 1002, and more specifically, the data processor 1602, performs checks on the extracted data selected by the user to ensure that the values ​​are within a predetermined range and / or are of a specified type. The application 1002 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 field that provide a threshold or acceptable range of values. For example, metadata or rules for a weight data field may specify that the predetermined acceptable range of values ​​is 20 kg to 200 kg. For values ​​outside the predetermined range, the application 1002 may display an error on the display interface 1022 or prompt the patient to record another image or correct the value.

[0263] 19 illustrates a flow diagram of an example procedure 1900 for inputting medical information from an image using the application 1002 of the personal mobile communication device 200a, in accordance with certain example embodiments of the present disclosure. While the procedure 1900 is described with reference to the flow diagram illustrated in FIG. 19, it should be understood that many other ways of implementing the steps associated with the procedure 1900 may also be used. For example, the order of many of the blocks may be changed, certain blocks may be combined with other blocks, and many of the described blocks may be optional. Additionally, the example procedure 1900 may include an optional block for prompting the patient to record an image of the screen and / or identifier 1012 of the medical device.

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

[0265] Prior to block 1906, the patient uses the application 1002 to select data fields and choose that medical information should be provided via photo entry. In block 1906, the personal mobile communication device 200a records an image 1907 of the medical device, supplies, patient, etc. The image may include an identifier and / or screen of the medical device. The personal mobile communication device 200a then determines or identifies text within the recorded image (block 1908). For example, the personal mobile communication device 200a may perform an OCR routine on the image. In cases where the image includes a barcode and / or QR code, the personal mobile communication device 200a decodes the barcode and / or QR code. The captured or coded data is converted into text or American Standard Code for Information Interchange ("ASCII") characters. In some embodiments, the personal mobile communication device 200a may also determine data fields for the identified text (block 1910). The data fields may be determined, for example, using a data template. 17 and 18, the data template may define the location of certain text and / or define certain textual indicators that are used to operatively place data fields over identified text in the recorded image. In some cases, the data fields and / or data templates may be selected by the patient and / or determined from the medical device identifier 1012. Alternatively, instead of using a template, the procedure 1900 may instead provide an indication that a recently recorded image has relevant medical information for extraction, selection, and / or transfer.

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

[0267] If no additional images are required, as determined at decision block 1912, the patient begins a process for populating the data fields of the user interface with relevant medical information. In the illustrated embodiment, the process includes allowing the patient to select an image for which relevant medical information should be transferred. Selection of the image causes the personal mobile communications 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, a data field. The patient may also specify the data field (or location within the data field) of the user interface into which the data should be populated.

[0268] The personal mobile communication device 200a receives a selection of relevant medical information and / or data fields with relevant medical information for entry into designated data fields of the user interface of the application 1002. The selection may be performed by the patient pressing an area of ​​the touchscreen 1002 of the personal mobile communication device 200a that corresponds to the medical information to be entered. The selection of the relevant medical information and / or fields, in some embodiments, causes the personal mobile communication device 200a to automatically enter at least a portion of the selected text (block 1916).

[0269] After the selected text is entered, the personal mobile communication device 200a determines whether additional associated medical information should be entered based on 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 the data fields. If additional associated medical information exists, as determined in decision block 1918, the procedure 1900 returns to blocks 1914-1916, where the patient specifies images and / or associated medical information for data field entry. If no additional associated medical information exists for entry, as determined in decision block 1918, the example procedure 1900 ends.

[0270] (4. Image / Text Attachment Application Embodiment) The exemplary application 1002 and clinician server 200b in some embodiments are configured to allow patients to provide images or text as attachments or addenda to their medical records. In the above section, the application 1002 provides user interface data fields as prompts for desired information. However, in some cases, the patient or clinician may wish to provide additional information. Additionally or alternatively, one or more user interfaces of the application 1002 may include data fields for free text entry, prompts for the patient to enter text (e.g., "How are you feeling today?"), or features to allow photos or images to be incorporated as part of the record. For example, the user interface 1400 may include a photo 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 the medical information. The image may be stored in a designated field within the appropriate patient medical record.

[0271] The exemplary application 1002 on the personal mobile communication device 200a is configured to accept images and / or text provided by the patient. In one embodiment, the application 1002 is configured to allow the patient to select text or photo entry. If the patient selects text entry, the application 1002 displays a text box. The patient enters information into the text box, which is stored by the application 1002. The application 1002 may then transmit the information in one or more messages to the clinician server 200b. The application 1020 on the clinician server 200b determines the appropriate patient medical record in the database 1010 and locates a "notes" or free text field. The application 1020 stores the patient-provided text in the field. In some cases, the 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 regarding treatment.

[0272] FIG. 20 illustrates an example user interface 2000 displayable by an application 1002 on a personal mobile communication device 200a that allows 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 that may be editable by the patient. The user interface 2000 also includes one or more recorded images 2004 or a preview of the recorded image. The application 1002 is configured to allow the patient to browse a gallery folder of recorded images and select an image to be transmitted. A date field 2006 and a time field 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 the image 2004 or an “upload” button to transmit the image 2004 from the application 1002 to the clinician server 200b. An exemplary photo capture feature of the application 1002 allows the patient to document physiological conditions related to fluid line connectivity with the home therapy machine 90 or treatment. An application 1020 on the clinician server 200b is configured to attach or otherwise link the received images 2004 to the patient's medical record.

[0273] 5. Manual / Wireless / Image Input of Medical Information via Text Embodiments In some embodiments, the personal mobile communication device 200a of FIGS. 10-12 may not be capable of installing or running the application 1002, or the patient may decide not to install the application 1002. However, the clinician server 200b still registers the personal mobile communication device 200a during the registration process. Instead of receiving medical information via the application 1002, the data acquisition module 1104 of the clinician server 200b determines that a routine or algorithm should be executed to prompt for or otherwise obtain medical information from the patient via the personal mobile communication device 200a. The exemplary data acquisition module 1104 may determine that the personal mobile communication device 200a is registered but does not have the application 1002 installed by reading the patient's registration file and / or medical record.

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

[0275] 11 is configured to format or otherwise structure the received information for population into one or more data fields of the patient's medical record. Generally, medical information received from a text message is unstructured. In other words, the text message does not provide a clear correlation or reference to a designated field of 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 the data field. For example, a patient may 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) to field data indicators, keywords, and / or metadata. If at least some of the words match, the data acquisition module 1104 is configured to identify numeric values ​​within the content of the text message and write the identified numeric values ​​into data fields in the patient's medical record that correspond to the matching text. In some embodiments, the data acquisition module 1104 may compare the value with an acceptable range of values ​​before writing it. If the value is outside the acceptable range, the data acquisition module 1104 may transmit a message to the personal mobile communication device 200a indicating an error or prompting the patient to re-enter the value.

[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 a received text message cannot be properly placed in a data field. For example, the data acquisition module 1104 may receive a message with text comprising "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. In response, 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 may be known or defined and correspond 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 associated with the prompt. For example, the data acquisition module 1104 transmits a text message prompting the patient for a "systolic blood pressure measurement." The data acquisition module 1104 determines that the response to the text includes a value for "systolic blood pressure measurement." The data acquisition module 1104 may analyze the received message to identify numeric values ​​from other text and / or to compare values ​​to acceptable ranges. After verifying that the patient has provided an acceptable response with medical information, the data acquisition module 1104 determines a subsequent message to send to the personal mobile communication device 200a based on the sequence of messages.

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

[0280] 21 shows a schematic diagram of a patient medical template 2100 that may be used by the data acquisition module 1104 of the clinician server 200b to populate data fields in a patient's medical record, according to certain exemplary embodiments of the present disclosure. The fields of the template 2100 may correspond to or otherwise be linked or referenced to 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 may be stored as the medical record itself. In some embodiments, the patient medical template 2100 may be part of or otherwise integrated with the patient's medical record.

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

[0282] It should be understood that in other embodiments, the patient medical template 2100 may include additional or fewer fields. For example, the template 2100 may additionally include data fields for pre-treatment and post-treatment patient weight, patient glucose level, and / or patient date of birth. In another example, the template 2100 may include fields for fill rate, dwell time, drain or fluid removal rate, blood flow rate, outflow rate, ultrafiltration removal rate, dialysate removal rate, total dialysate infused, dialysate flow rate, pre-exchange flow rate, post-exchange flow rate, patient weight balance, return pressure, indication of excess patient fluid, filtration rate, time remaining, 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 the template 2100 based on a prompt from the patient. For example, the patient may send a message including the text "manual replacement" to the data acquisition module 1104. In response, the data acquisition module 1104 identifies and selects the template 2100 for manual replacement. In another example, the patient may send a message including the text "pre-treatment" or "start treatment" to the data acquisition module 1104 via the personal mobile communications device 200a. In response, the data acquisition module 1104 identifies and selects a template for obtaining medical information needed before treatment can begin.

[0284] 21 , exemplary data fields include a field 2102 for the patient's name, a field 2104 for a 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 a treatment prescription identifier, and a field 2120 for a disposable cassette identifier. In instances 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) since such information is already provided by the machine 90. However, fields 2112-2180 may be used in the template if the patient reports a manual exchange. Additionally, template 2100 may omit fields 2102 and 2104 based at least in part on patient information already registered.

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

[0286] The patient medical template 2100 illustrated in Figure 21 is stored on the clinician database 1010 and is configured to be accessed by the clinician server 200b illustrated in Figures 10 and 11. Upon receiving a request to populate the template for a patient, the clinician server 200b is configured to copy or create an instance of the template 2100. Medical information received from the personal mobile communications device 200a is entered 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 a routine 2150 in conjunction with, or as an alternative to, the exemplary patient care template 2100. In some embodiments, the routine 2150 may be programmed as metadata or computer-executable code for the respective data fields 2102-2120. In other examples, the routine 2150 may be stored in the clinician database 1010 in association with the patient care template 2100. Furthermore, in these other examples, selection of the template 2100 causes the routine 2150 to be executed. The exemplary routine 2150 includes routine modules 2152-2164, which provide an association between the 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 may be associated with or otherwise related to a data template (e.g., data template 1700 of FIG. 17 ). The data acquisition module 1104 is configured to access the data template for the corresponding routine module 2152-2164 when the patient provides images and / or text in a message. For example, while executing the blood pressure routine module 2156, the data acquisition module 1104 transmits a message prompting the personal mobile communication device 200a for a “systolic blood pressure measurement.” The patient responds with a text message including 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 corresponding to or referenced by the blood pressure measurement routine module 1156. The data acquisition module 1104 then applies the data template and, using the procedures described above in connection with FIGS. 16-19 , extracts text from the image and identifies relevant systolic blood pressure medical information for populating the blood pressure data field 2108 of the template 2100.

[0289] The 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 with text including "begin," "start," and / or "pre-treatment." Receipt of the message causes the data acquisition module 1104 to determine and initiate the routine 2150 for populating the data fields 2102-2120 of the template 2100. In another example, the data acquisition module 1104 transmits a first message defined by the routine 2150 to the patient at a predetermined time relative to the treatment. After receiving a response message with appropriate medical information from the personal mobile communication device 200a, the data acquisition module 1104 sequentially transmits the messages defined by the routine 2150. In this manner, the data acquisition module 1104 controls the acquisition of medical information from the patient according to a predetermined sequence. The data acquisition module 1104 may not transmit the next message in the sequence defined by the routine 2150 until an appropriate response message is received from the personal mobile communications device 200a (and medical information is populated into the specified data fields 2102-2120 of the 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 received medical information conforms to text requirements for the patient's name and / or patient identifier. For example, the patient band module 2152 may filter out or discard medical information related to the patient's name that includes numbers.

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

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

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

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

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

[0296] To populate the data fields, the data acquisition module 1104, in some embodiments, may read the names of the data fields 2102-2120 (and any corresponding metadata) and create and send a message to the patient prompting the recording of an image. In one example, the weight data field 2106 includes metadata identifying a weighing scale as the associated medical device. The data acquisition module 1104 determines that the 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 scale screen. In the illustrated embodiment, the data acquisition module 1104 may sequentially progress through the template 2100 (or the patient's medical record), searching for blank data fields and, as appropriate, requesting medical information from the patient via a message displayed by the personal mobile communication device 200a. Alternatively, the data acquisition module 1104 may progress through the template 2100 according to a predetermined order or sequence. For example, the data acquisition module 1104 may first search a data field associated with the patient's wristband, followed by a data field related to a weight scale medical device, a data field related to a blood pressure medical device, and a data field related to a renal failure therapy medical device.

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

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

[0299] The example data acquisition module 1104 includes a template processor 2204 configured to manage the writing or entry of medical information from the personal mobile communication device 200a into the patient medical template 2100 or record. For example, upon request from the 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 of FIG. 21), if available or configured, is used by the template processor 2204 to run routines (e.g., routine 2150) to acquire medical information from the personal mobile communication device 200a.

[0300] The example template processor 2204 is configured to identify messages from modules of routines (e.g., routine 2150) for transmission to the personal mobile communication device 200a. In some cases, the messages may be transmitted in a predetermined sequence to instruct or guide a clinician or patient through the process of populating a patient medical template. For example, the template processor 2204 may read module 2156 of routine 2150 of FIG. 21 and determine that a message prompting the patient to record an image of the identifier 1012c of the scale 106 should be transmitted. The template processor 2204 may be configured to wait until medical information associated with the identifier 1012c is received (for populating the data field 2106 of FIG. 21) before identifying a message from the routine module 2156 to be transmitted. 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 the identifier 1012c of the weighing scale 106. In response to the received medical information, the template processor 2204 may determine that the module 2154 corresponds to the received data and, accordingly, select a message prompting the patient to record an image of the screen of the weighing scale 104. As illustrated in FIG. 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 the message, the template processor 2204 may be configured to select a data template, which in the illustrated embodiment is stored in a 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 the identifier 1012. In some cases, the patient may specify the model and / or type of medical device type to the template processor 2204 via the message. Furthermore, as discussed above, the template processor 2204 may receive images from the personal mobile communication device 200a, extract text from the images, and select an appropriate data template from the database 2208 to 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 the personal mobile communication device 200a containing substantially all of the medical information for the patient medical template 2100 or the patient's medical record. In these embodiments, the template processor 2204 reads indicia, metadata, and / or device data field information provided with the data to determine the data fields of the template 2100 into which the data should be populated or written. The template processor 2204 may, for example, match the module's metadata or information (or the data fields 2102-2120 themselves) to the indicia, metadata, and / or device data field information provided with the medical information to determine the appropriate data fields of the template 2100.

[0303] After populating or otherwise completing the patient medical template, the template processor 2204 of FIG. 22 is configured to store the completed template in the clinician database 1010. This may include populating the patient's medical record using the template 2100, where fields in the template correspond to, are linked to, or referenced to fields in the patient's medical record. In other examples, populating the medical record may include storing the populated template in the patient's medical record, or storing the template 2100 as the medical record itself.

[0304] 23 and 24 are flow diagrams of example procedures 2300 and 2350 for populating the medical device template 2100 of FIG. 21 using images recorded by (and / or text messages received from) the personal mobile communications device 200a of FIGS. 10-12 and 22, according to certain example embodiments of the present disclosure. While the procedures 2300 and 2350 are described with reference to the flow diagrams illustrated in FIGS. 23 and 24, it should be understood that many other ways of implementing the steps associated with the procedures 2300 and 2350 may also be used. For example, the order of many of the blocks may be changed, certain blocks may be combined with other blocks, and many of the described blocks may be optional. In certain embodiments, the order of the blocks may be modified if a persistent connection does not exist between the clinician server 200b and the personal mobile communications device 200a. Instead, in an embodiment, the personal mobile communications device 200a may initially obtain and queue substantially all relevant medical information for the patient medical template until (or by design) a connection with the clinician server 200b becomes available. The actions described in procedures 2300 and 2350 may be performed between multiple devices, including, for example, the personal mobile communications device 200a and the clinician server 200b.

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

[0306] After providing the patient medical template for data entry, the clinician server 200b determines (using a routine associated with the template or by reading the template itself) at least one medical device for which medical information is needed 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, instructions indicating that an image of the medical device's identifier 1012 should be recorded. After some time, the clinician server 200b receives a message 2307 including 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 of FIG. 17) based on the information included in the message 2307 or information defined in the patient's medical record (block 2310). For example, after determining that the message 2307 identifies the blood pressure monitor 104 (type and / or model), the clinician server 200b determines or finds a device data template for the blood pressure monitor 104. The clinician server 200b loads the device data template to identify relevant medical device data from the received image of the blood pressure monitor 104 screen (block 2312).

[0307] The exemplary procedure 2300 continues in FIG. 24 , where the clinician server 200b transmits a second camera message 2313 to the personal mobile communications device 200a (block 2314). The second camera message 2313 may be determined based on the type of medical device specified by message 2307. Additionally, the second camera message 2313 may include information for displaying a window (or associated medical information) on the medical device for recording the image. Sometime later, the clinician server 200b receives a message 2315 containing text from or an image of the medical device window (block 2316). The exemplary clinician server 200b uses the identified data template to extract associated medical information from the image and determines or otherwise identifies data fields in the patient medical template that correspond to the associated medical information (block 2318). If the message 2315 includes text, the clinician server 200b determines or otherwise identifies data fields in the patient medical template that correspond to the associated medical information. The clinician server 200b then populates the relevant received medical information into the determined and / or identified data fields of the template (block 2320).

[0308] After populating the associated data fields, the example clinician server 200b determines whether additional associated medical information is needed from the medical device associated with the received associated medical information (decision block 2322). For example, the clinician server 200b may determine that the current medical device may include an additional window or operating display for which associated medical information is still needed. If additional medical information is needed, the example clinician server 200b returns to block 2314 and transmits a camera message 2313 for another window for which associated medical information is needed. However, if no additional medical information is needed for the current medical device, the clinician server 200b determines whether 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 the associated 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 the procedure 2300 ends.

[0309] The example procedure 2350 begins in FIG. 23 by the personal mobile communication device 200a transmitting (2352) a message 2301 indicating a treatment to be administered to the patient or a request to begin entering medical information. The personal mobile communication device 200a then receives a camera message 2305 from the clinician server 200b. Information from the 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 the 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 input from the patient (block 2356). In some embodiments, the patient may enter text or select from a drop-down menu specifying the medical device type / model if the identifier is not available or if the patient does not want (or is unable) to record an image.

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

[0311] The personal mobile communication device 200a then receives a camera message 2313 from the server 200b with information for displaying a prompt to the patient to record an image of the screen (or other defined area) of the medical device (block 2360). The personal mobile communication device 200a responsively displays a prompt to the patient with the information needed 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 screen (or other defined area) of the medical device (block 2362).

[0312] 24, the example procedure 2350 continues by the personal mobile communication device 200a creating a text message with the recorded image or text entered by the patient (block 2364). In some examples, the patient may modify or define the medical information. The personal mobile communication device 200a then transmits a message 2315 including 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 the medical device associated with the extracted relevant medical information (decision 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 the camera message 2313 for another window (or portion of a medical device / consumable item) for which relevant medical information is needed. However, if no additional medical information is needed for the current medical device, the personal mobile communication device 200a determines whether medical information is needed from another medical device (or consumable item 1006) (decision block 2370). If additional medical information is needed, the personal mobile communication device 200a returns to block 2354 and processes the camera message 2305 identifying another medical device for imaging. If no additional medical information is required for completion of the patient medical template, the example personal mobile communications device 200a ends the session, thereby terminating the procedure 2350.

[0314] (6. Manual / wireless / image medical information entry via web browser or file transfer) In some embodiments, the data acquisition module 1104 of FIG. 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 allows the personal mobile communication device 200a to provide medical information and / or images without using an application 1002. In this embodiment, the clinician server 200b hosts websites, APIs, and / or file transfer sites that are assigned addresses or uniform resource locators ("URLs"). 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 the personal mobile communication device 200a has previously registered and provides access. In yet other embodiments, 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 the user interfaces 1400 and 1500 described in connection with Figures 14 and 15. Similar to the personal mobile communication device 200a including the application 1002, the clinician server 200b provides a user interface and data fields for receiving medical information. The data acquisition module 1104 may also allow the patient to select a data entry method, such as text or images.

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

[0318] FIG. 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 the blood pressure monitor 104 of FIG. 10. The clinician server 200b applies a data template 1801 to the image and extracts a set of text, as shown in fields 1802, 1804, 1806, 1808, and 1810. The patient selects fields 1802, 1804, 1806, 1808, and 1810 whose text should be entered into one or more selected data fields of the website 2502. In this manner, clinician server 200b allows patients to provide medical information via a website, file transfer program, or API.

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

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

[0321] The 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 data should be transmitted. The data access module 1106 determines the capabilities based on registration information indicating whether the application 1002 is installed and / or whether the personal mobile communication device 200a is a feature-rich device. To view the medical information on the application 1002, the data access module 1106 uses one or more APIs to convert the medical and / or treatment information from the HL7 format to, for example, HyperText Markup Language ("HTML") format, JavaScript Object Notation ("JSON") format, or XML format (e.g., an application format). If the data access module 1106 determines that the application 1002 is not installed, the data access module 1106 converts the information from HL7 format to, for example, a text message or SMS message format via one or more APIs. The example data access module 1106 thus allows patient medical record information to be viewed by patients regardless of the capabilities of their personal mobile communication device 200a.

[0322] (1. Information Display Embodiment 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 the 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 instances, fields from the medical records are referenced into fields of the user interface of the application 1002.

[0323] 26-29 show diagrams of an application 1002 on a personal mobile communication device 200a that displays medical information provided by the 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 lists the different user interfaces available. The application 1002 may be configured to receive medical information via one or more APIs that are linked to data fields in the patient's medical record. In other words, 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] 26 provides a first graph 2602 illustrating the total UF removed per day and a second graph 2604 illustrating the average UF removed per separate day / night exchange. It should be understood that the medical information displayed in graphs 2602 and 2604 may originate from home therapy machine 90 and / or one or more medical devices. The data access module 1106 of clinician server 200b provides access to medical information from different sources, so 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 the graphs 2602 and 2604 to provide additional treatment information. The user interface 2600 allows the patient to select a time range for the graphs 2602 and 2604. After receiving the selection, the application 1002 transmits a message indicating the selection to the data access module 1106. In exchange, the data access module 1106 provides the requested medical information.

[0326] 27 illustrates the average drain time for each UF exchange. The drain time is provided in graph 2702. Between user interfaces 2600 and 2700, the patient can gauge how their treatment is progressing over time. Any deviations in treatment will be readily apparent, helping to persuade the patient to adhere to the prescribed regimen.

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

[0328] In some examples, treatment information for manual replacement is entered by the patient via application 1002 on the personal mobile communication device 200a, while machine 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 a clinic. The information may be organized based on the machine from which the information was received, program name, treatment type, prescription, etc. The user interface 2900 in the illustrated example accordingly provides a single display of UF removed for the different replacements, thereby providing patient information regarding the effectiveness of the manual replacement compared to the machine-operated replacement. The example system 100 of FIG. 10 allows information from both replacements to be stored together (based on the day of treatment) for subsequent display and / or analysis.

[0329] (2. Information Display Embodiment via Web Browser) In some embodiments, the personal mobile communication device 200a may not have the application 1002 installed. Instead, the patient may use a web browsing application to access a website or interface hosted by the clinician server 200b. In these embodiments, the data access module 1006 is configured to display medical and / or treatment information in one or more web pages, similar to the user interfaces 2600-2900 of Figures 26-29. In this embodiment, the personal mobile communication device 200a accesses the data access module 1106 via a website. Selection of a user interface or feature via the personal mobile communication device 200a causes the data access module 1106 to display the medical information within the web page. The data access module 1106 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. Information Display Embodiments via Text In some embodiments, the data access module 1106 is configured to provide medical and / or treatment information to the personal mobile communication device 200a via text message. In these examples, the data access module 1106 may provide the information in response to a text received from the personal mobile communication device 200a. In other examples, the data access module 1106 may transmit the medical and / or treatment information to the patient's personal mobile communication device 200a periodically (e.g., daily, weekly, etc.).

[0331] In one example, the data access module 1106 may receive a text message containing the text "Sending 7 days of UF data." In response, the 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. The data access module 1106 may then use a lookup table or keyword search to identify a field in the patient's medical record containing a matching set of characters or text related to UF data (e.g., "7 days of UF"). The 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. Additionally or alternatively, the data access module 1106 creates and renders a 7-day graph, similar to graph 2602 of FIG. 26. The 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 .jpeg, .gif, .png, etc. file. The patient of the personal mobile communication device 200a may view the graph via text message. In this manner, the example data access module 1106 is configured to provide patient access to medical and treatment information regardless of the capabilities and / or operating system of their personal mobile communication device 200a. Additionally, the data access module 1106 determines how data should be transmitted based on registration information provided by the patient and / or an indication of whether the application 1002 is installed on the patient's personal mobile communication device 200a.

[0332] 4. Alarm / Alert Embodiments 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 rules table that specifies the devices to which certain alarms / alerts should be transmitted. Clinicians 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 the application 1002 is installed, the data access module 1106 provides the alarms / alerts through an appropriate user interface of the application 1002. In some cases, the application 1002 is configured to display a notification indicating the alarm / alert. If the application 1002 is not installed, the data access module 1106 determines that the 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, a condition may compare a single data value or trend (e.g., a 30-day rolling average) to a range of acceptable values ​​and / or thresholds (which may include hard and / or soft limits). In other examples, an alarm or alert may be generated based on multiple conditions based on comparing different types of information to respective limits. In some cases, the data access module 1106 determines derived information calculated from treatment and / or medical information, which is then compared to acceptable ranges. The following provide examples of alarms / alerts that may be transmitted by the data access module 1106 via text message and / or displayed within the 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 a 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, specify 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 explaining to the patient what will happen to their body if the treatment is not performed in a timely manner. If the data access module 1106 detects, for example, that treatment information has not 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 and provides an indication of the seriousness of the non-adherence to the treatment. As mentioned above, alarms and / or alerts may be transmitted by the data access module 1106 based on whether the application 1002 is installed. Even if the application 1002 is installed, the data access module 1106 is configured to transmit a text message to the personal mobile communication device 200a to alert the patient.

[0336] In some instances, the patient is prescribed a manual exchange. Therefore, the patient is required to provide treatment information indicating the manual exchange. The data acquisition module 1106 is configured to transmit an alarm or alert if the manual exchange information is not received within a predetermined period (e.g., within two days after the scheduled treatment). Furthermore, if the manual exchange is not properly completed (e.g., short fill or dwell time), the data access module 1106 sends an alert and / or alarm regarding an insufficient exchange. To determine an insufficient exchange, the data access module 1106 may compare the fill, dwell, and / or drain times to pre-established acceptable ranges and / or thresholds. In some instances, the data access module 1106 may require the patient to perform a complete exchange.

[0337] In some examples, alarms and / or alerts may be generated to indicate that the patient should select a different treatment program from multiple prescribed treatment programs or adjust the treatment program. In this example, an alarm or alert rule may specify that the data access module 1106 should calculate and compare the accumulated fluid value to a threshold while comparing the patient's blood pressure or weight to respective change thresholds. The accumulated fluid value may be determined from individual fluid fill and drain volumes, which indicate the fluid remaining in the patient's abdominal cavity. If the blood pressure or weight and accumulated fluid value (or trend) are outside of 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 drain duration (or shorter fill duration) should be selected (or the treatment program should be adjusted to provide a longer drain duration or shorter fill duration). The data access module 1106 transmits the alarm for display on the personal mobile communication device 200a. The patient may respond via application 1002 or text message to cause clinician server 200b to make appropriate changes to the patient's prescription or therapy program.

[0338] In some embodiments, the alarm and / or alert may define conditions under which additional information should be prompted from the patient. In these embodiments, the data access module 1106 uses treatment information from the home therapy machine 90 as the basis for determining whether the patient should provide medical information via the personal mobile communication device 200a. In one example, the data acquisition module 1106 may access 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, the alarm or alert may define that a prompt for a new blood pressure measurement is required if a blood pressure value (or trend) exceeds a predetermined threshold. In another example, the alarm or alert may define that a prompt for a new blood pressure measurement is required if an 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 the application 1002 for the patient to perform and record a blood pressure measurement. In some cases, the application 1002 may open a user interface (e.g., user interface 3000 of FIG. 30) that prompts the patient to enter blood pressure information. If the additional data received from the personal mobile communication device 200a is not within an acceptable range, the data access module 1106 may escalate the alert to an alarm that is transmitted to the clinician device 152 and / or the personal mobile communication device 200a. Thus, the data access module 1106 is configured to operate rules that determine borderline patient conditions that require additional information from the patient before determining whether further attention or action is required from the clinician or patient.

[0339] In further embodiments, rules in the data access module 1106 may instruct the patient to check the home therapy machine 90 and / or make changes thereto. In one example, a rule may specify 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 administered, which the data access module 1106 uses to determine that an alert regarding treatment adherence is not necessary. Instead, the data access module 1106 determines that an alert should be transmitted to the patient to check the network connection of the home therapy machine 90 so that treatment information stored on the machine 90 can be retrieved. The patient may respond to the alert using the personal mobile communications device 200a to indicate that the connection has been checked. After a response from the patient is received, the data acquisition module 1104 may send a ping message to the home therapy machine 90 regarding the missing treatment information. If a connection still cannot be made, 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 that specify that an alert should be generated in response to therapy information being out of range. For example, a large difference between fluid fill and drain volumes may indicate a leak in the dialysis tubing or the connection to the patient. In response, the data access module 1106 transmits an alert to the patient prompting the patient to verify the fluid connections. The patient may provide a response indicating whether a leak was detected. In response, the data access module 1106 determines whether the leak was corrected in a subsequent therapy cycle (or primary sequence) or whether the tubing should be replaced. The data access module 1106 may determine similar consumable issues with cassettes, cartridges, etc. based on the therapy and / or medical information. For example, a low 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. Therapy Control Module Embodiments The example therapy control module 1110 of FIG. 11 is configured to allow a 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 therapy (e.g., automated peritoneal dialysis therapy, manual exchange therapy, hemodialysis therapy, etc.), the duration for which the patient should receive therapy, the glucose level or other concentrate level of the therapy fluid, the daily amount of UF to be removed, and / or the number of times per day or duration range for each therapy. Each prescription may include one or more programs. A program may specify the therapy duration, the total volume of fluid to be provided to the patient, the number of fill, dwell, and drain cycles to be repeated, and / or an indication of whether the therapy includes tidal therapy. Variations in the programs within a prescription allow the patient or clinician to modify certain therapy parameters based on the patient's condition or activity.

[0342] The prescriptions and associated programs are stored in an electronic prescription in the clinician database 1010. In some embodiments, the prescriptions may be stored in the patient's medical record. 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., therapy control module 1110) may send a copy of the prescription from the clinician database 1010 to the home therapy machine 90 after registration.

[0343] In some embodiments, the example therapy control module 1110 is configured to operate in conjunction with the application 1002 on the personal mobile communication device 200a and / or an application on the clinician device 152 to allow the patient and / or clinician to select different prescription programs and / or prescriptions. FIG. 31 shows a schematic diagram of a user interface 3100 of the application 1002 that allows the patient to select between three different programs: a short-term program, a long-term program, and a weekend program. The patient may select a program based on their activity and / or situation. In some embodiments, the application 1002 may display alerts from the data access module 1106 providing recommendations to change the program based on detected accumulation of fluid, 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 to the therapy control module 1110 indicating the selection. In response, the therapy control module 1110 updates the patient's medical record to reflect the changed program, including the time / date of the change. Additionally, the therapy 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 therapy parameters related to the newly selected program. The home therapy machine 90 then responds by implementing the next therapy based on the newly selected program. In some cases, the home therapy machine 90 may display a prompt for the patient to confirm the new program before acting on the program.

[0345] In some embodiments, the therapy control module 1110 may perform checks to verify whether the patient is authorized to change programs and / or whether the change is permitted. For example, the therapy control module 1110 receives an indication that the patient wishes to change from a short-term program to a long-term program. The therapy control module 1110 compares the patient's medical information to one or more thresholds to ensure that the change will not adversely affect the patient. For example, the therapy control module 1110 may not approve a 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 therapy control module 1110 sends a message to the personal mobile communications device 200a indicating why the change cannot be made.

[0346] In certain embodiments, the therapy control module 1110 may send a notification to the clinician device 152 indicating that the patient wants to change the program. The therapy control module 1110 may not communicate the changes to the home therapy machine 90 until confirmation is received from the clinician device 152. In some embodiments, a clinician may change the program and / or prescription via the therapy control module 1110 using their clinician device 152. In these embodiments, the therapy control module 1110 may send a message for display in the application 1002 of the personal mobile communication device 200a indicating the change 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 the application 1002, the therapy control module 1110 is configured to allow changes to the prescription. For example, the therapy control module 1110 may host a website accessible by a web browser on the personal mobile communication device 200a. The website may include features similar to the user interface 3100 of FIG. 31 to allow the patient to remotely select a different program and / or prescription.

[0348] Additionally or alternatively, the therapy control module 1110 is configured to enable therapy changes via text message. In one example, the patient may send a message from the personal mobile communication device 200a including the text "change therapy." In response, the therapy control module 1110 is configured to send a reply message with different therapy program options and a corresponding code or indicator next to each option. The patient may enter the indicator or code in the reply message to select the desired program. In another example, the patient may send a message with text consisting of, for example, "long-term program" to have the therapy control module 1110 change the program to a long-term program.

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

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

[0351] As also described herein, incentives include text, audio, video, or multimedia presentations designed to improve the patient's mood or help the patient adhere to 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 one example of incentives, different status levels may be provided to patients based on their rate of adherence (e.g., "Dialysis Superstar" for near-perfect adherence).

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

[0353] In one example, the data access module 1106 determines that a patient is not adhering to 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 regarding the importance of adherence. FIG. 32 shows an example user interface 3200 of the application 1002 displaying an educational video related to adherence provided by the education module 1108. The example user interface 3200 also provides a list of recommended educational materials based on the patient's detected condition. For example, after detecting from a medical record or receiving as medical information that a patient has high blood pressure, the education module 1108 is configured to recommend educational content about lowering blood pressure. Furthermore, after detecting that the patient has not changed their prescription program, the education module 1108 determines that educational content explaining program options should be recommended.

[0354] The example education module 1108 may detect how the patient interacts with the application 1002 and recommend educational content. For example, the education module 1108 may receive feedback from the application 1002 indicating that the patient has made multiple attempts at populating data fields in a user interface (e.g., user interface 14 of FIG. 14 ) using recorded images. In response, the education module 1108 may provide a notification via the application 1002 recommending that the patient view a tutorial on entering information using recorded images.

[0355] The example education module 1108 may store any educational content or encouraging instructions displayed by the personal mobile communication device 200a in the patient's medical record. Such information may be useful to clinicians to determine how the patient is engaging with treatment. The stored information may also provide an indication of the patient's attitude toward treatment.

[0356] F. Auxiliary Module Embodiments 12 is configured to create a communication session between a patient's clinician. Specifically, the auxiliary module 1112 is configured to create a communication session between the clinician device 152 and the personal mobile communication device 200a. The auxiliary module 1112 may use the capabilities of the personal mobile communication device 200a to determine an appropriate communication session.

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

[0358] In some embodiments, the patient may initiate a session. The application 1002 is configured to allow the patient to request contact with a clinician (including specifying a preferred communication method). Using the text feature of the 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 the clinician's record associated with the patient and send a ping / request message to that device. A response received from one of the devices 152 provides an indication that the clinician is available and willing to communicate with the patient. In some cases, the response may indicate the clinician's communication method. In response to the received message, the auxiliary module 1112 initiates a communication session. This may include establishing a web call, a messaging session, or an audio call between the personal mobile communication device 200a and the clinician device 152. In some embodiments, instead of broadcasting a ping message to a group of clinicians, the assistance module 1112 may send ping / request messages to clinicians sequentially according to a predetermined order (e.g., first, the primary clinician, second, on-call clinicians in the same office, third, on-call clinicians in a different office, etc.). FIG. 33 shows a schematic diagram of a user interface 3300 of an application 1002 that provides video sessions with clinicians. The video session allows the patient to address their concerns about their treatment. The video session also allows the clinician to view real-time settings of the treatment or assist the patient in setting up the treatment.

[0359] In some embodiments, the auxiliary module 1112 may determine that a communication session should be opened or recommend opening a communication session. The auxiliary module 1112 may provide recommendations in conjunction with the data access module 1106 generating alarms and / or alerts. After detecting an alert and / or alarm condition, the auxiliary module may identify clinician devices 152 available to join the session and then initiate a call to the personal mobile communication device 200a to address the alert and / or alarm. 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 changes significantly within a predetermined period of time.

[0360] The exemplary assistance module 1112 may determine the type of assistance being sought to identify the correct individual for connection. In addition to clinicians, the assistance module 1112 may be capable of connecting to information technology specialists and home therapy machine specialists. Before starting a session, the application 1002 may prompt the patient to identify the assistance type (e.g., application help, machine help, clinical help, etc.). In other instances, the assistance module 1112 may determine the assistance type based on the context in which the request for the session was received. For example, after reviewing an educational training program for the home therapy machine 90, the assistance module 1112 determines that a subsequent request for assistance is related to operating the home therapy machine 90. In another example, while the application 1002 is displaying a user interface related to UF trends, the assistance module 1112 determines that a subsequent request for assistance is related to a clinical problem.

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

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

Claims

1. A system for transmitting therapy information from a home therapy machine, said system comprising: a clinician server; a personal mobile communication device including an application storing first registration information for communicating with the clinician server over an internet connection; A home therapy machine assigned to a patient, the home therapy machine comprising: (i) communicatively coupled to the clinician server via a separate Internet connection defined by second registration information, and (ii) communicatively coupled to the personal mobile communications device via a local connection; configured to transmit treatment information related to a renal failure therapy treatment administered to said patient as defined by a prescription; Home therapy machines, a clinician database communicatively coupled to the clinician server, the clinician database configured to store the treatment information from the home therapy machine in the patient's electronic medical record; Equipped with the home therapy machine is configured to transmit the therapy information to the personal mobile communications device when the second registration information is not available or the separate Internet connection is not available; The system, wherein the application on the personal mobile communications 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 described in 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 of claim 1, wherein the first registration information includes at least one of an Internet address of the clinician server, an identifier of the clinician server, application programming interface ("API") information for connecting to the clinician server, or an identifier of at least one of the patient or the home therapy machine.

4. The system of claim 1, wherein the clinician database is configured to store registration information in a patient registration file, the registration information specifying at least one of a patient activation code ("PAC"), information indicative of 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 described in claim 1, wherein the home therapy machine includes at least a renal failure therapy machine or an infusion pump.

6. The system of 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 regarding consumable items, volume data of fluid infused, 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 of claim 1, wherein the personal mobile communication device is a smartphone, a cellular telephone, or a tablet computer.

8. The system of claim 1, wherein the personal mobile communications device is communicatively coupled to the home therapy machine via at least one of 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 configured to transmit a new prescription to the application on the personal mobile communications device when registration information for the home therapy machine is not available; The system of claim 1 , wherein the personal mobile communications device is configured to transmit the new prescription to the home therapy machine for a subsequent renal failure therapy treatment.

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

11. A method for transmitting therapy information from a home therapy machine, said method comprising: storing first registration information within the personal mobile communications device for communicating with a clinician server over an internet connection; storing second registration information within the home therapy machine for communicating with the personal mobile communications device; generating within the home therapy machine treatment information related to a renal failure therapy treatment to be administered to the patient as defined by the prescription; determining within the home therapy machine that direct communication with the clinician server via a separate internet connection is not possible; after determining that the direct communication with the clinician server via the separate internet connection is not possible, transmitting the generated therapy information from the home therapy machine to the personal mobile communications device using the second registration information; transmitting the treatment information from the personal mobile communications device to the clinician server using the first registration information; A method comprising:

12. The method of 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 of claim 12, wherein the clinician database is configured to store registration information in a patient registration file, the registration information specifying at least one of a patient activation code ("PAC"), information indicative of the personal mobile communications 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 of claim 11, further comprising converting the treatment information to Health Level 7 ("HL7") format via the personal mobile communication device before transmitting the treatment information to the clinician server.

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

16. The home therapy machine includes at least a renal failure therapy machine or an infusion pump, 12. The method of claim 11, wherein the therapy information includes at least one of blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual exchange data, consumable data regarding consumable items, volume data of fluid infused, 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 of claim 11, wherein the personal mobile communication device is a smartphone, a cellular phone, or a tablet computer.

18. The method of claim 11, wherein the personal mobile communications device is communicatively coupled to the home therapy machine via at least one of 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.

19. The method comprising: transmitting a new prescription from the clinician server to the personal mobile communications device when registration information for the home therapy machine is not available; transmitting the new prescription from the personal mobile communications device to the home therapy machine for a subsequent renal failure therapy treatment; The method of claim 11 further comprising:

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

Images