Medical fluid delivery system including a 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 Art

[0001] Engaging with patients outside the medical environment over a long period of time is currently a virtually impossible task. Like joining a gym or buying a treadmill, many patients are typically prone to being enthusiastic at first. For example, from the start, patients are likely to readily embrace self-administered medical treatments (such as medical fluid delivery treatments) at home. Regarding the treatment, the patient needs to connect themselves to a medical fluid delivery machine (or a container containing renal failure treatment fluid) to clean their blood from the accumulation of toxins. Part of the treatment may include tasks that the patient needs to perform, such as weighing themselves, measuring their blood, and / or recording information related to their treatment. The information recorded by the patient is often scrutinized by the clinician to ensure that the treatment is progressing as prescribed. The clinician also examines the recorded data to determine whether adjustment of the treatment is required.

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

Summary of the Invention

Means for Solving the Problems

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

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

[0005] In addition, the exemplary medical fluid data transfer system provides a gateway to the clinician to enable the patient to communicate with the clinician in real time regarding any concerns or questions about the 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 the patient to the assistance needed or required to continue to participate in and / or comply with the treatment.

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

[0007] The above modalities may be provided by a medical fluid delivery machine that houses components necessary for delivering medical fluid, such as one or more pumps, valves, a heater if needed, a directly-connected medical fluid generating device if needed, a pressure sensor, a conductivity sensor, a temperature sensor, an air detector, a blood leak detector, etc., one or more of these sensors, a user interface, and a control unit that may employ one or more processors and memory for controlling the devices described above. The medical fluid delivery machine may also include one or more filters, such as a dialyzer or hemofilter for cleaning blood and / or an ultrafiltration filter 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 system can be used with home HD, HF, or HDF machines that are operated according to the convenience of the patient. One such home system is described in U.S. Patent No. 8,029,454 (the " '454 Patent"), issued on October 4, 2011, entitled "High Convection Home Hemodialysis / Hemofiltration And Sorbent System," filed on November 4, 2004, and assigned to the assignee of the present application. Other such home systems are described in U.S. Patent No. 8,393,690 (the " '690 Patent"), issued on March 12, 2013, entitled "Enclosure for a Portable Hemodialysis System," filed on August 27, 2008. The entire contents of each of the above-referenced documents are hereby incorporated by reference and relied upon.

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

[0010] In a first aspect of the present disclosure, which may be combined with any other aspect enumerated herein, unless otherwise specified, in light of the disclosure of this specification and without in any way limiting the present disclosure, a machine-accessible device, when executed, causes the machine to operate a camera to record an image, operate a display interface, and operate a connection interface configured to connect to a clinician database, where the clinician database is configured to store patient medical records, and has instructions stored thereon configured to cause a processor to operate to obtain medical information and enter data into the patient medical records of the clinical system. The processor is operative to obtain medical information by displaying, via the display interface, a user interface with fields into which medical information is to be entered, and, after selection of a data field of the user interface, graphically providing, via the display interface, a first option for entering medical information from an image and a second option for entering medical information via text input. When the first option is selected, the processor receives the image recorded by the camera, where the recorded image includes a medical device or the screen of a medical device, extracts text from the image, 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 as medical information into the data field of the user interface. When the second option is selected, the processor enables text input into the data field as medical information via the display interface. The processor is also operative to obtain medical information by transmitting the medical information written in the data field to the patient medical records stored in the clinician database after a transmit instruction is received.

[0011] According to a second aspect of the present disclosure that can be used in combination with any other aspect recited herein, unless otherwise stated, when executed, the machine-accessible device causes the machine to determine a data template for the extracted text on the image, use the data template to process the extracted text, classify the extracted text into fields, enable selection of at least one of the fields, and further includes instructions stored thereon that configure the processor to write the selected text from the image into a data field of the user interface.

[0012] According to a third aspect of the present disclosure that can be used in combination with any other aspect recited herein, unless otherwise stated, the data template is configured to define the context for the text extracted in relation to the text position within the image.

[0013] According to a fourth aspect of the present disclosure that can be used in combination with any other aspect recited herein, unless otherwise stated, when executed, the machine-accessible device causes the machine to determine the data template based on at least one of (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) a label within the extracted text, or (iv) the relative arrangement of the extracted text, and further includes instructions stored thereon that configure the processor to do so.

[0014] According to a fifth aspect of the present disclosure that can be used in combination with any other aspect recited 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 the housing of the medical device or on the screen of the medical device.

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

[0016] According to a seventh aspect of the present disclosure that can be used in combination with any other aspect recited herein unless otherwise stated, the data fields of the user interface are configured to receive at least one of blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual exchange data, subjective data, or consumable data regarding a consumable item.

[0017] According to an eighth aspect of the present disclosure that can be used in combination with any other aspect recited 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, an adsorbent cartridge, and a water purification container.

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

[0019] According to a tenth aspect of the present disclosure, which can be used in combination with any other aspect recited herein unless otherwise specified, a method of entering data into a patient medical record in a clinical database using a recorded image includes transmitting, to a personal device, a first message that prompts the patient to record a first image of a medical device using a camera of the personal device, and receiving the first image from the personal device. The method also includes determining, from the first image, via a processor, first medical information 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, to the personal device, via the processor, a second message that prompts the patient to record a second image of a screen of the medical device using the camera. The method further includes receiving the second image from the personal device via the processor, extracting text from the second image via the processor, and processing the extracted text and classifying the extracted text into fields using the data template via the processor. The method still further includes writing, via the processor, at least a portion of the text from at least one of the fields into the patient medical record.

[0020] According to an eleventh aspect of the present disclosure, which can be used in combination with any other aspect recited herein unless otherwise specified, 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 into the record field in the patient medical record.

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

[0022] According to a thirteenth aspect of the present disclosure that can be used in combination with any other aspect recited herein unless otherwise stated, the method further includes receiving, in a processor, a treatment message from a personal device indicating that the patient should begin treatment and transmitting a first message via the processor prior to the treatment being initiated.

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

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

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

[0026] According to a seventeenth aspect of the present disclosure, which can be used in combination with any other aspect recited herein unless otherwise stated, a system for transmitting information to a patient includes a patient's home therapy machine configured to transmit therapy information, a medical record, and a clinician database configured to store 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 therapy 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 stores therapy information and medical information in the medical record, receives an instruction that at least a portion of the therapy information and medical information should be displayed on the personal device, and is configured to determine from the registration file whether the application is installed on the personal device. If the application is installed, the clinician server is configured to convert at least a portion of the therapy information and medical information into an application format for display within the application and transmit at least the converted portion of the therapy 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 therapy information and medical information into a text message or short message service ("SMS") format and transmit at least the converted portion of the therapy 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 can be used in combination with any other aspect recited 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 that may be used in combination with any other aspect recited herein, unless otherwise specified, the instruction that at least a portion of the treatment information and medical information should be displayed on a personal device includes at least one of a message from an application or a text / SMS message from the personal device.

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

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

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

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

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

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

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

[0036] Providing improved patient compliance is yet a further advantage of the present disclosure.

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

[0038] Providing a medical fluid data transfer system and methodology that enables communication between a medical fluid delivery machine and multiple individuals such as a patient and a clinician or a patient and a primary caregiver is yet a further advantage of the present disclosure.

[0039] Furthermore, in many cases, it is an advantage of the present disclosure to reduce waste of disposable sets and other auxiliary textile products due to disposal that occurs when a mechanical 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 become apparent from the following detailed description of the invention and the figures. The present invention further provides, for example, the following. (Item 1) A machine-accessible device storing instructions that, when executed, cause a machine to input data into a patient medical record of a clinical system, and inputting data into the patient medical record includes operating a camera to record an image, operating a display interface, operating a connection interface configured to connect to a clinician database, the clinician database being configured to store patient medical records, operating a processor to obtain medical information by acquiring the medical information involves displaying, via the display interface, a user interface with fields for entering medical information after selection of a data field of the user interface, graphically providing, via the display 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 an image recorded by 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 part of the text from the image via the display interface writing the selected text from the image as the medical information to the data field of the user interface and if the second option is selected, enabling text input to the data field as the medical information via the display interface after a transmission command is received, transmitting the medical information written to the data field to a patient medical record stored in the clinician database by a machine-accessible device (Item 2) further comprising instructions stored in the machine-accessible device, which when executed are configured to cause the machine to operate the processor, and the processor determining a data template for the extracted text on the image using the data template to process the extracted text and classify the extracted text into fields Enable selection of at least one of the fields and write the selected text from the image to the data field of the user interface The machine-accessible device according to item 1, which performs the above operations (Item 3) The machine-accessible device according to item 2, wherein the data template is configured to define context regarding the extracted text in relation to the text position within the image (Item 4) The machine-accessible device according to item 2, further comprising instructions stored in the machine-accessible device, which when executed, are configured to cause the machine to operate the processor, and the processor is configured to (i) select 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 the markings within the extracted text, or (iv) based on the relative arrangement of the extracted text, determine the data template (Item 5) The machine-accessible device according to item 4, wherein the identifier located on the medical device includes at least one of a housing of the medical device or a quick response ( "QR") code, barcode, serial number, or hardware number located on the screen of the medical device (Item 6) The machine-accessible device according to 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 scale, and a heart rate monitor (Item 7) The machine-accessible device according to item 1, wherein the data field of the user interface is configured to receive at least one of blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual exchange data, subjective data, or consumable data regarding a consumable item (Item 8) The consumable item is the machine-accessible device according to item 7, including at least one of a filter, a blood line set, a dialysate concentrate container, a blood anticoagulant container, a drug container, a disposable cassette, an adsorbent cartridge, and a water purification container. (Item 9) The machine is the machine-accessible device according to item 1, which is a personal mobile communication device. (Item 10) A method of inputting data into a patient medical record in a clinical database using a recorded image, 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 indicating a type or model of the medical device from the first image; determining, via the processor, a data template and a second message associated with the determined type or model of the medical device; transmitting, via the processor, the second message to the personal device, the second message prompting the patient to record a second image of a screen of the medical device using the camera; receiving the second image from the personal device via the processor; extracting text from the second image via the processor; processing the extracted text using the data template and classifying the extracted text into fields via the processor; writing at least a portion of the text from at least one of the fields to the patient medical record via the processor and including. (Item 11) Determining, via the processor, a correspondence between one of the fields and a record field within the patient medical record; Writing, via the processor, at least a portion of the text from the field to the record field within the patient medical record; The method according to item 10, further comprising: (Item 12) Determining, via the processor, a treatment time from the patient medical record; Transmitting, via the processor, the first message prior to the treatment time; The method according to item 10, further comprising: (Item 13) Receiving, at the processor, from the personal device, a treatment message indicating that the patient should begin treatment; Transmitting, via the processor, the first message prior to the treatment being initiated; The method according to item 10, further comprising: (Item 14) The method according to item 10, wherein the first image is received at the processor via a first text message or a first Short Message Service (SMS) message, and the second image is received at the processor via a second text message or a second SMS message. (Item 15) The method according to item 10, further comprising converting, via the processor, at least a portion of the text from at least one of the fields to a Health Level 7 (HL7) format prior to writing to the patient medical record. (Item 16) Comparing, via the processor, at least a portion of the text from at least one of the fields to a predetermined range; Writing at least a part of the text from at least one of the fields when at least a part of the text from at least one of the fields is within the predetermined range via the processor The method according to item 10, further comprising. (Item 17) A system for transmitting information to a patient, the system comprising: The patient's home therapy machine configured to transmit treatment information; A clinician database configured to store the medical record and the registration file, wherein the registration file 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 the medical information; A clinician server communicatively coupled to the clinician database, the home therapy machine, and the personal device Comprising The clinician server: Storing the treatment information and the medical information in the medical record; Receiving an instruction that at least a part 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 at least a part of the treatment information and the medical information into an application format for display within the application; Transmitting at least a part of the converted treatment information and medical information to the personal device Performing If the application is not installed, Converting at least a portion of the treatment information and the medical information into a text message or Short Message Service ("SMS") format; Transmitting at least a portion of the converted treatment information and medical information to the personal device via one or more text messages or SMS messages; And performing; A system configured to perform. (Item 18) The system according to 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) The system according to item 17, wherein the instruction that at least a portion of the treatment information and the 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) The system according to item 17, wherein the registration file is included in the medical record. (Item 21) The home therapy machine is configured to store a prescription using two programs, each of the programs providing parameters for operating the home therapy machine to perform a treatment, and the clinician server Receiving a program message indicating a change from a first program to a second program from the personal device; Transmitting program instructions for changing from the first program to the second program to the home therapy machine; The system according to item 17, which is configured to perform.

Brief Description of the Drawings

[0041]

Figure 1

[0042]

Figure 2

[0043]

Figure 3

[0044]

Figure 4

[0045]

Figure 5

[0046]

Figure 6

[0047]

Figure 7

[0048]

Figure 8

[0049]

Figure 9

[0050]

Figure 10

[0051]

Figure 11

[0052]

Figure 12

[0053]

Figure 13

[0054]

Figure 14

Figure 15

[0055]

Figure 16

[0056]

Figure 17

[0057]

Figure 18

[0058]

Figure 19

[0059]

Figure 20

[0060]

Figure 21

[0061]

Figure 22

[0062]

Figure 23

Figure 24

[0063]

Figure 25

[0064]

Figure 26

Figure 27

Figure 28

Figure 29

[0065]

Figure 30

[0066]

Figure 31

[0067]

Figure 32

[0068]

Figure 33

[0069] A medical fluid delivery system is disclosed herein. An 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 a patient with increased transparency regarding their treatment and at least some degree of control over their treatment while providing resources for educating or otherwise assisting the patient throughout the treatment process. The exemplary medical fluid delivery system is configured to provide patient engagement regardless of the type or characteristics of the medical device or the patient's personal mobile communication device associated with the treatment. 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 at 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, and the hub enables the personal mobile communication device to provide features designed to involve the patient in medical fluid delivery treatment.

[0071] As disclosed herein, an exemplary clinician server receives medical fluid delivery data (e.g., treatment information) from the medical fluid delivery machine, and the delivery data is stored in one or more patient records within the clinician database. The clinician server provides access to the medical fluid delivery data to the personal mobile communication device, enabling the patient to track treatment progress. Additionally, the patient may use the personal mobile communication device to change (or request to change) the treatment program. The request is routed through the clinician server to verify that the change is appropriate before being transmitted to the medical fluid delivery machine.

[0072] An exemplary clinician server operates in relation to the personal mobile communication device to enable the patient to provide medical information such as vital sign data, medical device data, etc. without effort. The personal mobile communication device is configured to allow the patient to manually enter data, record a photo including data from connected medical devices such as a scale, blood pressure monitor, thermometer, glucose meter, etc., and / or receive data wirelessly therefrom. 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 entered into the patient's medical record.

[0073] As disclosed herein, the personal mobile communication device can include a feature-rich smart device such as a smartphone or a tablet computer. The smart device can operate a specialized application (e.g., an "app") defined by instructions stored in memory. Execution of the stored instructions causes the application to operate within the processes of the smart device, and the application is configured to improve a patient's engagement in medical treatment. In some instances, the personal mobile communication device can include a feature-poor conventional cellular phone with significantly less processing power and features compared to a smart device. The cellular device can operate using text messages and / or specialized applications (e.g., apps) defined by instructions stored in memory. Applications for feature-poor devices can have fewer features compared to applications for smart devices.

[0074] The following disclosure is separated into two sections. The first section discloses an embodiment of a medical fluid delivery system. The second section discloses features that enable the medical fluid delivery system to improve a patient's engagement and / or compliance in medical treatment.

[0075] (I. Medical Fluid Delivery System Embodiment) An exemplary medical fluid delivery system includes one or more medical fluid delivery machines. An example of a medical fluid delivery machine is a renal failure treatment machine. With respect to a renal failure treatment machine, due to various causes, a patient's renal system is unable to function. Renal failure causes several physiological disturbances. Maintaining the balance of water and minerals or excreting the daily metabolic load is no longer possible. Toxic end products of nitrogen metabolism (urea, creatinine, uric acid, and others) can accumulate in the blood and tissues.

[0076] Renal insufficiency and reduced kidney function are treated using dialysis. Dialysis removes waste products, toxins, and excess water from the body that a normally functioning kidney would otherwise remove. Dialysis treatment for replacement of kidney function is important to many people because the treatment is life-saving.

[0077] One type of renal insufficiency treatment is hemodialysis ("HD"), which generally uses diffusion to remove waste products from a patient's blood. A diffusion gradient occurs across a semipermeable dialyzer between the blood and an electrolyte solution called 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 performed by adding replacement fluid or substitution fluid (typically, 10 - 90 liters of such fluid) to the extracorporeal circuit during treatment. The replacement fluid and the fluid accumulated by the patient between treatments provide a convective transport mechanism that is ultrafiltered over the course of the HF treatment and is particularly beneficial in removing medium and large molecules (in hemodialysis, a small amount of waste products is removed along with the fluid obtained between dialysis sessions, however, solute extraction from the removal of that ultrafiltrate is not sufficient to provide convective clearance).

[0079] Hemodiafiltration ("HDF") is a treatment modality that combines convective and diffusion clearance. HDF uses a dialysis fluid flowing through a dialyzer, similar to standard hemodialysis, to provide diffusion 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. There is a trend towards home hemodialysis ("HHD") today because, in part, HHD can be performed daily and offers therapeutic benefits superior to in-center hemodialysis treatments (typically performed two or three times a week). Studies have shown that more frequent treatments remove more toxins and waste products than less frequent, and perhaps longer, treatments received by patients. Patients receiving more frequent treatments do not experience 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 miles away from a patient's home, which causes door-to-door treatment times that consume most 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, which involves injecting dialysis fluid, also called dialysate, into the patient's peritoneal cavity through a catheter. The dialysis fluid contacts the peritoneum of the peritoneal cavity. Waste products, toxins, and excess water flow from the patient's bloodstream, through the peritoneum, and into the dialysis fluid due to diffusion and osmosis, i.e., an osmotic gradient occurs across the membrane. Osmotic agents in dialysis provide the osmotic gradient. Used or spent dialysis fluid is drained from the patient, removing waste products, toxins, and excess water from the patient. This cycle is repeated multiple times, for example.

[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. Here, the patient manually connects an implanted catheter to a drain to enable the used or spent dialysis fluid to be drained from the peritoneal cavity. The patient then connects the catheter to a bag of fresh dialysis fluid to inject the 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 remain in the peritoneal cavity, and the transfer of waste products, toxins, and excess water occurs. After a certain dwell period, the patient repeats the manual dialysis procedure, for example, four times a day, and each treatment lasts about one hour. Manual peritoneal dialysis requires a significant amount of time and effort from the patient and there is room for improvement.

[0083] Automated peritoneal dialysis ("APD") is similar to CAPD in that the dialysis treatment involves drain, fill, and dwell cycles. However, the APD machine typically performs the cycles automatically while the patient is sleeping. The APD machine liberates the patient from the need to perform the treatment cycles manually and the need to carry supplies during the day. The APD machine is 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, into the patient's peritoneal cavity. The APD machine also enables the dialysis fluid to dwell in the cavity, allowing the transfer of waste, toxins, and excess water to occur. The source can include multiple sterile dialysis fluid bags.

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

[0085] Any of the modalities performed by the machine can be executed on a schedule and may require a startup procedure. For example, dialysis patients typically undergo treatment on a schedule such as every other day, daily, etc. A blood treatment machine typically requires a certain amount of time before treatment, for example, for settings for performing disinfection procedures. Patients undergoing the above modalities may have a busy life and have plans to execute or errands to run on the days when the treatment is scheduled.

[0086] Much of the appeal of home treatment for patients is centered around the lifestyle flexibility provided by enabling patients to primarily perform treatment at home according to their own schedules. However, a home medical fluid delivery machine may include software timers that instruct and constrain the user or patient. A home hemodialysis system, for example, may require the patient to be in close proximity to the home hemodialysis machine in order to initiate sequences before, during, and after treatment.

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

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

[0089] In one embodiment, the system of the present disclosure provides a software application (an "app") installed on a patient and / or caregiver's personal mobile communication device, such as a smartphone. The app is provided, in one embodiment, via a middleware software application, an example of which is discussed in detail below. In an alternative embodiment, the software is configured to communicate with a patient and / or caregiver's personal mobile communication device, such as a smartphone, using directly the text messaging feature through the middleware software application. In either case, the app or text message is constructed, in one embodiment, to remind the patient of any impending deadlines without connecting the patient to the machine and to enable the patient and / or caregiver to track when treatment needs to be started.

[0090] Alternatively, or in addition, it is contemplated that communication software be constructed to automatically program reminders on a user's mobile communication device, e.g., on the device's native task tracking features 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 systems and methodologies of the present disclosure can access the smartphone calendars of authorized patients and / or caregivers and be programmed to enter appropriate information, e.g., that the machine starts or completes disinfection within that time segment, into the appropriate time segment of the appropriate day.

[0091] In one embodiment, the communication from the software systems and methodologies of the present disclosure is one-way. For example, the 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 systems and methodologies of the present disclosure enable two-way communication between a medical fluid delivery machine and a patient's or caregiver's mobile communication device. In one example, the two-way communication can enable a machine routine to be remotely initiated by a patient or caregiver using their mobile communication device. One exemplary routine is an automated self-test routine, which can be carried out without any user interaction with the system other than starting or beginning the sequence. Remotely starting the sequence can benefit the patient or caregiver, e.g., by providing additional time for the patient or caregiver to be away from the machine to perform other tasks. The communication becomes two-way when the machine initiates communication by indicating that it is in a state where it can carry out the self-test routine. The patient or caregiver responds to the machine via the software systems and methodologies of the present disclosure at a desired time to start the sequence.

[0092] Whenever the machine is in the "patient connected" software state, it is assumed that the software of the systems and methodologies of the present disclosure disables communication between the patient and / or caregiver and the machine. For example, if a clinician attempts to send a command to a machine that is currently treating a patient, the command can be blocked by the middleware software application so that the command is not transferred to that machine. The middleware software application can then reply to the clinician, informing that the machine is busy and not accepting communication.

[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 drugs ("IV"). The examples are particularly well-suited for all forms of hemodialysis ("HD"), hemofiltration ("HF"), hemodiafiltration ("HDF"), continuous renal replacement therapy ("CRRT"), and peritoneal dialysis ("PD"), collectively or generally individually referred to herein as renal insufficiency treatment. The medical fluid delivery machine can alternatively be a drug delivery or nutritional fluid delivery device such as a large volume peristaltic type pump or a syringe pump. The machines described herein can be used in a home setting. For example, a machine operating in the data transfer modality of the present disclosure can be employed with a home HD machine that can be activated, for example, at night while the patient is sleeping. The medical fluid data transfer system and methodology of the present disclosure can alternatively be used to assist clinicians or nurses in a hospital and / or clinic.

[0094] Referring now to the drawings, and in particular to FIG. 1, a medical fluid data transfer system 10 operating within a medical fluid delivery machine 90 is illustrated. 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 of different types (e.g., a mixture of HD, PD, CRRT, and medical or nutritional fluid delivery).

[0095] Although a single medical fluid delivery 90 is illustrated as communicating with a connection server 118, system 10 monitors the operation of multiple medical fluid delivery systems and machines of the same type or different types 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 server 118 and operating with system 10. The numbers from M to R can be the same or different numbers and can be zero, 1, or two or more. In FIG. 1, the medical fluid delivery machine 90 is illustrated as a home treatment machine 90 (the home is indicated by the dashed line).

[0096] The home treatment machine 90 can receive purified water from a water treatment device 60 as discussed above at its front end. The water treatment device 60 is connected to the home treatment machine 90 via an Ethernet (registered trademark) cable in one embodiment. The home treatment machine 90 in the illustrated embodiment operates with other devices such as a blood pressure monitor 104, a meter, for example, a wireless meter 106, and a user interface such as a wireless tablet user interface 122 other than the water treatment device 60. The home treatment machine 90 is connected wirelessly to the server 118 via a modem 102 in one embodiment. Each of these components can be located within the patient's home as bounded by the dashed line in FIG. 1 (although it is not necessary to be so). Any one, two or more, or all of the components 60, 104, 106, and 122 can communicate with the home treatment machine 90 either wired or wirelessly. The wireless communication can be via Bluetooth (registered trademark), WiFi (registered trademark), Zigbee (registered trademark), Z-Wave (registered trademark), wireless universal serial bus ("USB"), infrared, or any other suitable wireless communication technology. Alternatively, any one, two or more, or all of the components 60, 104, 106, and 122 can communicate with the home treatment machine 90 via wired communication.

[0097] The connection server 118 communicates with the medical fluid delivery machine 90 via the medical device system hub 120. The system hub 120 enables data and information regarding each home treatment machine 90 and its peripheral devices to pass to and from the machine 90 and other clients connected to the server 118 via the connection server 118. In the illustrated embodiment, the system hub 120 is connected to the service portal 130, the enterprise resource planning system 140, the web portal 150, the business intelligence portal 160, the HIPAA-compliant database 124, the product development team 128, and an electronic medical record database maintained, for example, at clinics or hospitals 126a-126n.

[0098] The electronic medical record (「EMR」) database at clinics or hospitals 126a-126n stores electronic information about patients. The system hub 120 can send data collected from the log files of the machine 90 to the hospital or clinic databases 126a-126n to merge or supplement the medical records of that patient. The databases at clinics or hospitals 126a-126n may contain patient-specific treatment and prescription data, and thus access to such databases can be highly restricted. The enterprise resource planning system 140 acquires and compiles data generated via patient and clinician website access, such as complaint, invoicing information, and lifecycle management information. The web portal 150 enables patients and clinics 152a-152n treating the patients to access a publicly available website for users of the medical fluid delivery machine 90. The business intelligence portal 160 collects data from the system hub 120 and provides the data to marketing 162, research and development 164, and quality / drug safety monitoring 166.

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

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

[0101] In one embodiment, the home treatment machine 90 writes log files, for example, using the Linux® operating system. The log files document relevant data of the home treatment machine 90, including peripheral device data. The log files can include any one or more of an Extensible Markup Language ("XML"), comma-separated values ("CSV"), or text files. The log files are installed in the file server box of the software of the home treatment machine 90. It is also envisioned that data not sent to the machine 90 is stored in a peripheral device, for example, the water treatment device 60. Such data can alternatively be obtained via a wired or wireless connection to the peripheral device or downloaded through other data connections or storage media. For example, a maintenance person can access additional data via, for example, a laptop connected to the water treatment device 60 or the wireless meter 106 via an Ethernet® connection. Or, additional data can be read remotely from the peripheral device, and the home treatment machine 90 serves as a data transfer communication path between the peripheral device and an authorized client of the medical fluid data transfer system.

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

[0103] The connection agent 114 enables the home treatment machine 90 to connect to the connection server 118 and transfer data to and from the connection server 118. The connection service operating via the agent 114 and the server 118 ensures that the connection to the machine 90 is secure, that data correctly passes through the firewall of the machine 90, checks whether there are data or system crashes, and ensures that the connection server 118 is communicating with the correct home treatment machine 90.

[0104] In one embodiment, the home treatment machine 90 can connect to the connection server 118 only when the connection agent 114 is turned on or activated. During treatment and post-treatment disinfection, while the machine 90 and its peripheral devices are functioning, in one embodiment, the connection agent 114 is turned off, which prevents the home treatment machine 90 from communicating with any entity and transmitting or receiving data during treatment and disinfection, or when the machine 90 is operating or starting up. When the home treatment machine 90 is in an idle state, for example, after treatment and post-treatment disinfection are completed, the ACPU 50 turns on the connection agent 114 in one embodiment. In certain embodiments, the connection agent 114 is off during treatment and perhaps also during pre-treatment. After treatment, the connection agent 114 uses the connection service to read a log file from the home treatment machine 90 and transfer the data to the connection server 118. The connection service routes data packets to their appropriate destinations, but in one embodiment, does not modify, access, or encrypt the data.

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

[0106] (A. Exemplary Medical Fluid Delivery Machine) Referring now to FIG. 2, an example of an HD flow schematic diagram for a medical fluid delivery machine 90 is illustrated. Since 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 and for IV, drug delivery, or nutritional fluid delivery machines. Generally, a medical fluid delivery machine 90 having a simplified version of a dialysis fluid or process fluid delivery circuit is shown. The blood circuit is also simplified, but not to the extent that the dialysis fluid circuit is simplified. The circuits are simplified to make the description of the present disclosure easier, and it should be understood that the system, when implemented, will have additional structures 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 withdraws blood from the patient 12 and returns the blood thereto. The blood is withdrawn from the patient 12 via the arterial line 14 and returned to the patient via the venous line 16. The arterial line 14 includes an arterial line connector 14a, and the arterial line connector 14a is connected to an arterial needle 14b, and the arterial needle 14b is in blood sampling communication with the patient 12. The venous line 16 includes a venous line connector 16a, and the venous line connector 16a is connected to a venous needle 16b, and the venous needle 16b is in blood return communication with the patient. The arterial and venous lines 14 and 16 include line clamps 18a and 18v, which can be spring-loaded fail-safe mechanical pinch clamps. The line clamps 18a and 18v are automatically closed in an emergency in one embodiment.

[0108] The arterial and venous lines 14 and 16 also each include an air or bubble detector 22a and 22v, which can be ultrasonic air detectors. The air or bubble detectors 22a and 22v each detect air in the arterial and venous lines 14 and 16. When air is detected by one of the air detectors 22a and 22v, the system 10 closes the line clamps 18a and 18v, temporarily stops the blood and dialysis fluid pumps, and provides instructions to the patient to purge the air so that the treatment can be resumed.

[0109] In the illustrated embodiment, the blood pump 30 is located within the arterial line 14. In the illustrated embodiment, the blood pump 30 includes a first blood pump pod 30a and a second blood pump pod 30b. The blood pump pod 30a operates with an inlet valve 32i and an outlet valve 32o. The blood pump pod 30b operates with an inlet valve 34i and an outlet valve 34o. In certain embodiments, each of the blood pump pods 30a and 30b is a blood container, and they include, for example, a spherical rigid outer shell with a flexible diaphragm located within a shell, forming a diaphragm pump. One side of each diaphragm receives blood, while the other side of each diaphragm is actuated by positive and negative air pressures. 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, the heparin vial 24 and the heparin pump 26 are located between the blood pump 30 and the blood filter 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). Supplying heparin upstream of the blood filter 40 helps prevent clotting of the filter membrane.

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

[0112] In the hemodialysis version of the medical fluid delivery machine 90 of FIG. 2, the dialysate is pumped along the outside of the membrane of the hemofilter 40, while the blood is pumped through the inside of the hemofilter membrane. The preparation of the dialysate begins with the purification of water via the water purification unit 60. One suitable water purification unit is described in U.S. Patent Publication No. 2011 / 0197971, filed Apr. 25, 2011, entitled "Water Purification System and Method" (the entire contents of which are incorporated herein by reference and relied upon). In one embodiment, the water purification unit purifies tap water (e.g., removes ions such as pathogens and chlorine) such that the water is, in one implementation, below 0.03 endotoxin units / ml ("EU / ml") and below 0.1 colony forming units / ml ("CFU / ml"). The water purification unit 60 can be provided in a housing separate from the housing or chassis of the hemodialysis machine 90 that includes the blood circuit 20 and the dialysate circuit 70 of the hemodialysis machine 90.

[0113] The dialysis fluid circuit 70 is again greatly simplified in FIG. 2 for ease of illustration. The actual dialysis fluid circuit 70 can include all of the related 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 dialysis fluid pump 64 for the hemofilter. The pump 64 is configured the same as the blood pump 30 in one embodiment. The pump 64, like the pump 30, includes a pair of pump pods 66 each having an inlet valve 68i and an outlet valve 68o, which can again be configured spherically. The two pump pods are operated alternately, as with the blood pump 30, such that while one pump pod is being filled with HD dialysis fluid, the other pump pod is discharging HD dialysis fluid.

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

[0115] A fifth pod pump (not shown) provided in the drain line 82 is used to remove a known amount of ultrafiltration (「UF」) when HD treatment is provided. The system 10 tracks the UF pump to control and account for the amount of ultrafiltrate removed from the patient. The system 10 ensures that the required amount of ultrafiltrate is removed from the patient by the end of the treatment.

[0116] Each of the pumps described above may alternatively be a peristaltic pump that operates with a pressure pipe. If applicable, the system valve can still be pneumatically actuated in accordance with the features of the present disclosure.

[0117] In one embodiment, the purified water from the water purification unit 60 is pumped along the mixing line 62 through the bicarbonate cartridge 72. Acid from the container 74 is pumped into the bicarbonate water flowing from the bicarbonate cartridge 72 along the mixing line 62 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] FIG. 2 also shows that the dialysis fluid is pumped along the fresh dialysis fluid line 76 through the heater 78 and the ultrafiltration filter 80 before reaching the hemofiltration filter 40, and then the used dialysis fluid is pumped out through the discharge line 82. The heater 78 heats the dialysis fluid to body temperature or about 37° C. The ultrafiltration filter 80 further cleans and purifies the dialysis fluid before it reaches the hemofiltration filter 40 and filters out foreign substances and / or contaminants introduced into the dialysis fluid, for example, through the bicarbonate cartridge 72 or the acid container 74.

[0119] The dialysis fluid circuit 70 also includes a sample port 84 in the illustrated embodiment. The dialysis fluid circuit 70 further includes a blood leak detector (not shown but used to detect whether the fibers of the hemofiltration filter 40 are torn) and other components not shown, such as an equilibrium chamber, a plurality of dialysis fluid valves, and a dialysis fluid holding tank, which are all 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 series of operations passing system, where the system pumps dialysis fluid through a hemofilter once and then pumps the used dialysis fluid out for discharge. Both the blood circuit 20 and the dialysis fluid circuit 70 can be thermally disinfected 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 thermally disinfected daily and reused over about a month, while the dialysis fluid circuit 70 is thermally disinfected and reused over about six months.

[0121] In an alternative embodiment, for example, with respect to CRRT, a plurality of bags of sterile dialysis fluid or infusion fluid are grouped together and used one after another. In such a case, the empty supply bag can serve as a discharged or depleted fluid bag.

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

[0123] FIG. 3 illustrates that the machine 90 of FIG. 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] In FIGS. 2 and 3, any of pumps 26, 30 (30a and 30b), 64, 96 (and other pumps not shown) and any of valves such as valves 32i, 32o, 34i, 34o, 68i, 68o, 98i, and 98o can be pneumatically actuated. In certain embodiments, each of the pumps and valves has a fluid side and an air side separated by a flexible membrane. Negative pneumatic pressure can be applied to the air side of the membrane to draw fluid into the pump chamber or to open the valve (alternatively, the pump or valve can be opened by releasing a positive closing pressure to the atmosphere and allowing the fluid pressure to open). Positive pneumatic pressure is applied to the air side of the membrane to discharge fluid from the pump chamber or to close the valve.

[0125] (B. Exemplary Medical Fluid Delivery System Connectivity Embodiments) Referring now to FIG. 4, a system 110a of the present disclosure is illustrated. The system 110a in the illustrated embodiment operates with the system 10 described above, which includes a connection server 118, a system hub 120, a service portal 130, an enterprise resource planning system 140, a web portal 150, and a business intelligence portal 160, which are illustrated as part of a cloud environment in FIG. 4. Each of the connection server 118, the system hub 120, the service portal 130, the enterprise resource planning system 140, the web portal 150, and the business intelligence portal 160 can be part of a cloud environment or located on one or more dedicated servers.

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

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

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

[0129] In another example, the medical fluid delivery machine 90b may be pre-programmed to start treatment at 3:00 p.m. The medical fluid delivery machine 90b may require three hours for self-testing and disinfection. The patient 12a or the clinician 112a must therefore be next to the machine 90b by noon to start the pre-treatment. In certain embodiments, the patient 12a or the clinician 112a sets the machine 90b with respect to how far in advance of the three-hour preparation time the patient 12a or the 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 a.m. and send the code to middleware software stored on the system hub 120. The middleware software may then convert the code into a message such as "Please start preparing for treatment in two hours" using, for example, a lookup table, and display the message on an app downloaded on the mobile communication device 200b of the patient 12b or the clinician 112b. The app may be programmed to provide a visual identifier such as a countdown timer that counts down from 120 minutes to zero timeout along with the message. The app may also provide any one or more of an audio alert such as a "beeping" sound and / or a tactile alert such as vibration that prompts the patient 12b or the clinician 112b to view the app and confirm the treatment preparation notification. The app may also be programmed to repeat the "beeping" sound and / or the tactile feedback at pre-programmed intervals (e.g., one 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 code from the machine 90b into a message embedded on the device 200's native task-tracking features such as its calendar application. Most smartphone devices 200 are provided with a calendar that separates each day into time segments such as hours. Here, the message converted by the middleware software of the system hub 120 can be programmed to access the calendar of the authorized communication device 200b and enter appropriate information into the appropriate time segment of the appropriate day. In the above example, for the appropriate day, the native calendar software application would have its 10:0:00 AM time slot filled with a message such as "Please start preparing for treatment in 2 hours". Audio and / or tactile feedback signals can be provided to notify the patient 12 or clinician 112 about the calendar entry.

[0131] The machines 90a and 90b, the middleware software in the central server 120, and the communication devices 200a and 200b can be programmed and operated as described above to provide any desired message 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 can similarly be informed, using an accompanying countdown timer, that the treatment needs to start within the countdown time to avoid the need to re-disinfect the machines 90a, 90b at the end of the disinfection.

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

[0133] The system hub 120 in one embodiment stores middleware software that can be accessed by a mobile communication device 200 (shown as a single device for ease, but multiple devices 200 can similarly be connected to the system 110b). The mobile communication device 200 of FIG. 5 includes all of the structures, functionality, and alternatives (including being connected to the Internet 52) disclosed with respect to the devices 200a and 200b shown in FIG. 4. In FIG. 5, the mobile communication device 200 can download software applications ("apps") from the middleware software stored on the system hub 120 via their connections to the Internet 52, although this is not necessary. The apps can be operated as exactly described above in connection with FIG. 4 (including middleware software that converts the coded message from the machine 90 into a format presentable on the app). Alternatively, or in addition, the middleware software stored on the system hub 120 can convert the code from the machine 90 into a message that is embedded on the native task tracking features of the mobile communication device 200, such as its calendar application, in any of the ways described in FIG. 4.

[0134] As a further alternative or in addition, the system 110b includes, for example, a cellular network 210 that interfaces between middleware software stored in the system hub 120 and the mobile communication device 200. The cellular network 210 can include a network of cellular phone towers that operate using radio waves and / or can employ satellites. Suitable communication protocols for use with the cellular network 210 of the system 110b can be long-distance protocols such as (i) the "Worldwide Interoperability for Microwave Access" ("WiMAX") protocol and (ii) the "Global System for Mobile Communications" ("GSM®") protocol, a wide range of long-distance wireless protocols that enable data communication to many of the cellular phones around the world. The network 210 can alternatively or in addition employ a medium-distance protocol such as a wireless local area network ("WLAN") that can be a protocol that is part of the Institute of Electrical and Electronics Engineers ("IEEE") 802.11 standards, such as (i) IEEE 802.11a, (ii) IEEE 802.11b, (iii) IEEE 802.11g, or (iv) 802.11n. Other suitable cellular technologies can include CDMA, AMPS (analog), General Packet Radio Service ("GPRS"), cdmaOne, CDMA2000, Evolution-Data Optimized ("EV-DO"), GSM® Enhanced Data rates for GSM Evolution ("EDGE"), Universal Mobile Telecommunications System ("UMTS"), Digital Enhanced Cordless Telecommunications ("DECT"), Digital AMPS ("IS-136 / TDMA"), and Integrated Digital Enhanced Network ("iDEN").

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

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

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

[0138] A cellular message can convey information regarding either a software app that inputs information into the mobile communication device 200 or any of the same events discussed above regarding the calendar update mode. For example, the medical fluid delivery machine 90 may have just completed its automated self-test routine and is currently in a state where it can perform a disinfection procedure. The machine 90 can generate a code identifying this state and send it to the middleware software stored on the system hub 120. The middleware software can then convert the code into a message, such as "self-test complete, ready for disinfection," using, for example, a lookup table, and cause a text message to be sent to the mobile communication device 200 of the patient 12 or clinician 112 via, for example, the cellular output routine discussed above, causing the message to be displayed. In an alternative embodiment, the code is not required, and the machine 90 can instead send the actual text string, and the middleware software transfers it as a text message to the mobile communication device 200 via, for example, the cellular output routine discussed above. As is known, the receipt of a text message on the communication device 200 can be accompanied by an audio prompt, such as a "ringing" sound, and / or a tactile alert, such as vibration, to prompt 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 start treatment at 3:00 PM. The medical fluid delivery machine 90 may again require 3 hours for self-testing and disinfection. The patient 12 or the clinician 112 may therefore need to be near the machine 90 by noon to initiate pre-treatment. In certain embodiments, the patient 12 or the clinician 112 sets the machine 90 with respect to how far in advance of the 3-hour preparation time the patient 12 or the clinician 112 should be notified or alerted (e.g., 2 hours). Here, the machine 90 generates a code at 10:00 AM and transmits the code to middleware software stored on the system hub 120. The middleware software then converts the code into a message such as "Please start preparing for treatment in 2 hours" using, for example, a look-up table, and causes a text message to be sent to the mobile communication device 200 of the patient 12 or the clinician 112 via, for example, the cellular output routine discussed above, and displays the message with an audio alert such as a "beeping" sound that prompts the patient 12 or the clinician 112 to view the notification and / or a tactile alert such as vibration.

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

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

[0142] In one embodiment, the system hub 120 stores middleware software that can be accessed by a mobile communication device 200 (shown as a single device for ease, but multiple devices 200 can similarly be connected to the system 110b). The mobile communication device 200 of FIG. 6 includes all of the structures, functionality, and alternatives disclosed with respect to devices 200a and 200b shown in FIG. 4 (including being connected to the Internet 52). In FIG. 6, the mobile communication device 200 can download software applications ( "apps") from the middleware software stored on the system hub 120 via their connections to the Internet 52, although this is not necessary. The apps can be operated as described above in connection with FIG. 4 (including middleware software that converts the coded message from the machine 90 into a format presentable on the app). Alternatively, or in addition, the middleware software stored on the system hub 120 can convert the code from the machine 90 into a message embedded on the native task tracking features of the mobile communication device 200, such as its calendar application, in any of the ways described in FIG. 4. The calendar application can alternatively be updated via the cellular network 210 (shown as an alternative via a dashed drawn line in FIG. 6) discussed above in connection with FIG. 5.

[0143] FIG. 6 illustrates that communication can be two-way 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 via a securely managed connection 116, as described in detail above.

[0144] As discussed above, in one embodiment, the in-home treatment machine 90 connects to the connection server 118 via its on-board connection agent 114 that is turned off during treatment, e.g., while the machine 90 and its peripheral devices are functioning (which may or may not be during post-treatment disinfection). This prevents the in-home treatment machine 90 from communicating with any entity or transmitting or receiving data during treatment and disinfection, or while the machine 90 is operating or powered on. It is assumed that communication via systems 110a - 110c is protected in the same way. For example, assume that a particular machine 90 is set up via middleware software to communicate with both the patient 12 and the clinician 112. Here, it is assumed that the connection agent 114 is blocked so that when the patient is being treated by the machine 90, the clinician 112 does not receive a notification from or send a command to that 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 the connection agent 114 (no communication) may depend on the content or number of machine states that systems 110a - 110c desire to communicate to the mobile communication device 200. For example, assume that it is only desired to notify the patient 12 or the clinician 112 two hours before treatment preparation that they need to return to the machine 90 to start treatment preparation. Here, the connection agent 114 may be turned off as soon as the patient 12 or the clinician 112 starts the first treatment preparation step, e.g., executes a self-test routine.

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

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

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

[0149] FIG. 6 illustrates the following exemplary 7-step sequence. In step 1, the medical fluid delivery machine 90 sends a message indicating that the machine is in a state where the patient 12 can initiate the start of an automated self-test routine (e.g., for 2 hours) to a middleware software application at the system hub 120. In step 2, the middleware software application at the system hub 120 sends a corresponding (e.g., converted) message indicating that the machine 90 is in a state where the patient 12 can initiate the start of an automated self-test routine to the patient's mobile communication device 200.

[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 in a state where the patient can begin, for example, a 2-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 start 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 to confirm that it is desired for the patient's machine 90 to start its automated self-test routine. In step 6, the middleware software application in the system hub 120 sends (e.g., converts and sends) a message to the machine 90 indicating that the patient 12 has confirmed that the machine 90 should 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 assumed that the system 110c performs the same steps 1-7 discussed above, except that the action here is a disinfection procedure instead of the automated self-test routine. Here, the custom app downloaded to the patient's mobile communication device 200 may display a countdown timer to remind the patient 12 of the amount of time the patient has until returning to the machine 90 to start 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 is started.

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

[0154] (C. Clinician Device / Server Embodiment) Referring now to FIGS. 7 - 9, an embodiment of system 110d having a clinician - based downloadable software application (the "app") 230 for a mobile communication device or server 200 of a physician, clinician, or nurse is illustrated on screens 232 - 236. As discussed above, mobile communication device 200 can be that of patient 12 or that of physician / nurse / clinician 112. Screens 232 - 236 of FIGS. 7 - 9 illustrate that app 230 can be used in clinics or hospitals 126a - 126n, for example, where a nurse is involved with multiple machines 90a - 90n. Machines 90a - 90n can again be hemodialysis machines, peritoneal dialysis machines, CRRT machines, drug and / or nutrition fluid delivery machines, and combinations thereof.

[0155] Screen 232 illustrates that app 230 can monitor multiple machines 90 and, if desired, control them. In the illustrated embodiment, machines 90a - 90n are each represented by dedicated icons 190a - 190n displayed on screen 232 of app 230. Icons 190a - 190n in the illustrated embodiment are ordered on screens 232 - 236 the same as they are ordered within clinics 126a - 126c to help orient physician / nurse / clinician 112.

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

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

[0158] The middleware software of system hub 120 or local system hub 220 updates the status of each machine 90a - 90n. A nurse, clinician, or doctor 112 can select icons 190a - 190n at any time to view the current status of each machine 90a - 90n, such as "Idle", "Self - test", "Disinfection", or "Patient treatment in progress" as illustrated within screen 234 of FIG. 8. Other status markers are also envisioned and can vary for different types of machines. The nurse, clinician, or doctor 112 can then select any of "Idle", "Self - test", "Disinfection", or "Patient treatment in progress" to return to the home icons 190a - 190n as illustrated in FIG. 9.

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

[0160] Regarding the countdown timer, it is envisioned that the connection agent 114 enables the machines 90a - 90n to send remaining time data to the system hub 120, such that the app 230 can display the actual remaining time for each machine 90 that is subject to the timed process. The app 230 anticipates alarms or other delays that the machines 90 may encounter. During an alarm situation, the corresponding icons 190a - 190f can display messages such as "Alarm" or "Safe Mode". A 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] A nurse, clinician, or doctor 112 can toggle the alert on / off icon 238 to enable or disable the status changes regarding the machines 90a - 90n to be alerted visually, audibly, and / or tactilely. When the alert on / off icon 238 is switched to "On", the app 230 of the mobile communication device 200 will provide visual, audible, and / or tactile alerts, e.g., (i) "Self - test start", (ii) "Self - test complete", (iii) "Disinfection start", (iv) "Disinfection complete", (v) "Treatment start", (vi) "Treatment complete" each time the status of the machine changes. In certain embodiments, the codes regarding (i) - (v) are securely managed and transmitted via the machines 90a - 90n through the connection 116, connection server 118, and system hub 120 or local system hub 220, converted by middleware software, and transferred to the app 230, which updates the appropriate icon 190. In various embodiments, "(vi) Treatment complete" can be transmitted (a) via the machines 90a - 90n using the activated connection agent 114, or (b) can be inferred when the countdown timer of the appropriate icons 190a - 190n ends and the connection agent 114 may still be off.

[0162] When the alert on / off icon 238 is switched off, for example, if a nurse, clinician, or physician 112 does not desire to be interrupted at a given moment, the icons 190a - 190n are still updated as described above, but audible and / or tactile alerts are not provided. However, the nurse, clinician, or physician 112 can still actively view the status of each machine 90a - 90n by selecting the associated icons 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 can be provided for any modality, for example, any type of pre - treatment action required for hemodialysis, peritoneal dialysis, CRRT, drug, and / or nutritional fluid delivery. In the illustrated embodiment, action button 240a is for initiating a self - test regarding machine 90, while action button 240b is for initiating a disinfection sequence regarding machine 90.

[0164] In one embodiment, when the self-test button 240a is selected, any machine 90a-90n capable of performing a self-test at that time has its corresponding icon 190a-190n emphasized. A nurse, clinician, or doctor 112 selects any icon 190 related to the machine 90 that the nurse, clinician, or doctor 112 desires to perform a self-test on. The selected icon 190 can then change to a "confirm" button that the nurse, clinician, or doctor 112 needs to press again to cause the selected machine 90 to perform the self-test. The app 230 of the mobile communication device 200 then sends the corresponding self-test code to the middleware software in the system hub 120 or the local system hub 220, and the middleware software converts the self-test code into a self-test start command as needed. The command is sent to the connection agent 114 of the selected machine 90 via a connection 116 that is securely managed via the connection server 118. The connection agent 114 transfers the command to the ACPU 50 of the machine, and the ACPU 50, in turn, begins the self-test.

[0165] In the illustrated embodiment, when the disinfection button 240b is selected, any machine 90a-90n capable of performing disinfection at that time has its corresponding icon 190a-190n emphasized. A nurse, clinician, or doctor 112 selects any icon 190 related to the machine 90 that the nurse, clinician, or doctor 112 desires to perform disinfection on. The selected icon 190 can again change to a "confirm" button that the nurse, clinician, or doctor 112 needs to press again to cause the selected machine 90 to perform the disinfection. The app 230 of the mobile communication device 200 then sends the corresponding disinfection code to the middleware software in the system hub 120 or the local system hub 220, and the middleware software converts the disinfection code into a disinfection start command as needed. The command is sent to the connection agent 114 of the selected machine 90 via the secure connection 116 managed via the connection server 118. The agent 114 transfers the command to the ACPU 50 of the machine, and the ACPU 50, in turn, starts the disinfection.

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

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

[0168] In one embodiment, when a mobile communication device 200 transmits data to the system hub 120 or the local system hub 220 for delivery to the 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 convert the data from the mobile communication device 200 as discussed above, but in either case, the mobile communication device 200 identifier is maintained for the connection server 118. The connection server 118 knows, for each mobile communication device 200, which machine 90 should receive, for example, the converted data, and transmits the converted data to each associated communication device 200, for example. The connection server 118 may remove the mobile communication device 200 identifier from the data when it is delivered to the machine 90 as it is no longer needed.

[0169] The app 230 as described above enables a nurse, clinician, or physician 112 to set, monitor, and possibly control the treatment in the medical fluid delivery machine 90. It is envisioned to provide similar functionality to the patient 12 or a caregiver for the patient 12 at the patient's home (the dashed frame in FIG. 1) via the app. The connectivity can be the same as that shown in FIGS. 7-9. However, the setting is not at the clinics 126a-126n, but instead at other non-clinical locations such as the home or a business or vacation place. In addition, typically, there is only a single machine 90 instead of multiple machines 90a-90n. However, it is possible for a single patient 12 to be treated via multiple machines 90, and each of the multiple machines 90 can be supported by an app as described herein. When the patient 12 is at home but away from the machine 90, the app can provide useful information such as the amount of time left to start or complete a startup procedure task, a disinfection procedure, or a self-test routine. When the patient is being treated by the machine 90, the patient can view information on its user interface 122, which can itself be a tablet as illustrated in FIG. 1. However, there can also be a caregiver, such as a spouse, friend, or in-home nurse, who assists the patient 12 at home during treatment. The caregiver benefits from the home app by receiving status updates, the remaining time of the startup procedure, the remaining disinfection time, the remaining priming time, the remaining treatment time, information on 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, thereby allowing only authorized persons to 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 FIGS. 1-9 is configured to improve patient engagement in medical fluid delivery treatments such as dialysis treatment, renal failure treatment, and / or peritoneal treatment. FIG. 10 shows an exemplary medical fluid data transfer system 1000 similar to the medical fluid data transfer system 10 discussed in connection with FIGS. 1-9 according to an exemplary embodiment of the present disclosure. The exemplary medical fluid data transfer system 1000 (e.g., a mobile platform) is configured to improve patient engagement and / or compliance with the treatment by providing features for controlling and reporting treatment-related information to the patient to improve treatment transparency and / or by providing access to educational materials and / or real-time assistance from a clinician.

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

[0172] The home therapy machine 90 can include any type of hemodialysis machine, peritoneal dialysis machine, CRRT machine, drug and / or nutrition fluid delivery machine, and combinations thereof. The home therapy machine 90 can provide, for example, continuous cyclic peritoneal dialysis ("CCPD"), tidal flow automated peritoneal dialysis ("APD"), and continuous flow peritoneal dialysis ("CFPD"). The home therapy machine 90 can typically perform drainage, filling, and dwell cycles automatically while the patient is sleeping.

[0173] The peritoneal dialysis dialysate can include a solution or mixture containing 0.5% to 10%, preferably 1.5% to 4.25% glucose (or more generally, dextrose). The peritoneal dialysis dialysate can include, for example, Dianeal®, Physioneal®, Nutrineal®, and Extraneal® dialysates commercially available from the assignee of the present disclosure. The dialysate can, in addition or alternatively, include a percentage of icodextrin.

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

[0175] Exemplary scale 106 includes any device configured to measure the mass of a patient or a treatment component. For example, scale 106 can measure the patient's weight before, during, and / or after a renal failure treatment. In addition or alternatively, scale 106 can measure a supply or drainage bag to track a renal failure treatment. Specifically, scale 106 can be used to measure the amount of UF removed or the amount of fluid provided to the patient. Scale 106 can display a digital value indicating the weight. Alternatively, scale 106 can display a physical scale or dial aligned with a marker to indicate the measured weight. In some embodiments, scale 106 can store pre-treatment, during-treatment, and / or post-treatment weight values in a separate window such 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 a patient's blood pressure before, during, and / or after treatment for renal insufficiency. The blood pressure monitor 104 may display a digital value indicative of the patient's blood pressure. Alternatively, the blood pressure monitor 104 may display a physical scale with a dial aligned with a numerical value to indicate the measured blood pressure. In some embodiments, the blood pressure monitor 104 may store pre-treatment, during-treatment, and / or post-treatment blood pressure values in a separate window such 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 a 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 the patient and / or the therapy consumable item 1006. FIG. 10 shows an example of a consumable item 1006 that includes, for example, a renal insufficiency treatment medical device filter, a disposable cassette, a blood line set, a drug delivery line set, and containers (e.g., a dialysate concentrate container, a blood anticoagulant container, a drug container, and / or a water purification container). The consumable item 1006 may also include an adsorbent cartridge or any other disposable or substance source for medical treatment. The consumable item 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, serial number, and / or characteristics of the consumable item. In some cases, the consumable item 1006 may also include a label containing medical information such as chemical composition characteristics. The patient or clinician may use 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 can 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 may not be 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 input 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 data (or identifiers placed thereon) displayed by the home therapy machine 90, the blood pressure monitor 104, and / or the scale 106.

[0179] Collectively, the blood pressure monitor 104 and the scale 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”), a portable pump, a multi-channel pump), an oxygen sensor, a respiratory monitor, a glucose meter, a blood pressure monitor, an electrocardiogram (“ECG”) monitor, a weighing scale, and / or a heart rate monitor. In other examples, the medical fluid data transfer system 1000 may include fewer medical devices and / or medical devices integrated together (e.g., the blood pressure monitor 104 integrated with the home therapy machine 90).

[0180] In some embodiments, the personal mobile communication device 200a is configured to record, display, and / or enter medical information or data into a patient medical record. As disclosed herein, medical information or data includes medical device data and patient data, which may refer to data or information created by, generated by, or otherwise related to a medical device, a patient, and / or a consumable item used by the medical device. For example, medical information includes prescription or programming information used by a medical device to administer treatment. Medical information includes sensed data such as fluid pressure, flow rate, conductivity, concentration, temperature, and patient data. As provided herein, patient data (e.g., vital sign data) includes sensed 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, tired, satisfied, 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 label or on the 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 included 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 regarding a consumable item, which may identify characteristics of the consumable item such as consumable item type, consumable item model, and / or the level of glucose in a supply bag of a renal replacement therapy solution.

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

[0183] As shown in FIG. 10, some of all of the medical devices 90, 104, and 106 may include an identifier 1012 configured to store a unique identification number. The identifier 1012 may encode, for example, the assigned device number, serial number, hardware number, model number, and / or device type of each of the medical devices 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 within the recorded image. 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 scale and / or indicate the model number of the scale.

[0184] The identifier 1012 may include a machine-readable marking 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, an asset number, or a hardware number. In some embodiments, the identifier 1012, such as the identifier 1012b shown with respect to the home therapy machine 90, may be printed on an article physically attached to the housings of the respective medical devices 90, 104, and 106. Additionally, or alternatively, the identifier 1012 may be displayed on some of the screens 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 included 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 enable a user to navigate to a window or a user interface on the screen of the respective medical devices 90, 104, and 106. The control interface may also provide instructions for operating or controlling the respective medical devices 90, 104, and 106.

[0186] As shown in FIG. 10, the exemplary fluid data transfer system 1000 includes a web portal 150 (similar to each device discussed in relation to FIGS. 1-9), a system hub 120, and a clinician server 200b for communicating with a personal mobile communication device 200a. The web portal 150, the system hub 120, and / or the clinician server 200b transfer medical information from a patient's medical record (stored in the clinician database 1010) to the personal mobile communication device 200a. Additionally, 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 the 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 input into the patient's medical record.

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

[0188] In the example illustrated in FIG. 10, the exemplary personal mobile communication device 200a includes a processor 1016 that communicates with a memory 1018 that stores instructions. At least some of the instructions define or specify an application 1002 that, when executed by the processor 1016, causes the processor 1016 to provide features that improve a patient's engagement with and / or compliance with a 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 or disk storage medium.

[0189] As discussed in more detail below, the features of the application 1002 include displaying treatment progress information, controlling treatment programs initiated by the in-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-poor. A feature-rich application is configured for a smartphone and takes advantage of the personal mobile communication device 200a's native graphics, touch screen, and processing capabilities. A feature-poor application is configured to operate on a cellular phone having relatively less sophisticated graphics and reduced processing capabilities. The cellular phone may or may not include a touch screen, or alternatively may have a touch screen 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 some other installed application, to communicate with the clinician server 200b. For example, the personal mobile communication device 200a may use a text, SMS, or email program to communicate with the clinician server 1020.

[0191] The exemplary clinician server 200b includes an application 1020 such as application 230 described in connection with FIGS. 1-9. The application 1020 communicates with the personal mobile communication device 200a and is configured to provide improved patient engagement and / or compliance. In some embodiments, the exemplary application 1020 is configured to facilitate the storage of medical information (recorded by the personal mobile communication device 200a) to 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 touch screen) on the personal mobile communication device 200a. The application 1020 in the clinician server 200b may provide educational materials and / or facilitate a communication session between the personal mobile communication device 200a and the clinician's device 152 in response to a request from the application 1002.

[0192] In some cases, the application 1002 on the personal mobile communication device 200a and / or the application 1020 on the clinician server 200b are configured to convert or otherwise provide medical information to the clinician database 1010 of other devices within the medical fluid data transfer system 1000 that complies with the Health Level 7 ("HL7") standard (e.g., a medical standard). This conversion enables the medical information to be stored in the HL7 format regardless of the format when it is input into the personal mobile communication device 200a. The application 1002 and / or the application 1020 may act as a network conduit to seamlessly propagate relevant medical information from the medical device to the patient medical record when a gap in network or device connectivity exists.

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

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

[0195] Each of the exemplary modules 1102 - 1112 is configured to improve a patient's engagement in a medical fluid delivery treatment, thereby improving the patient's compliance with the prescribed treatment. Although the modules 1102 - 1112 are shown, it should be understood that the exemplary application 1020 may include fewer or additional modules. For example, in some embodiments, the education module 1108 and the assistance module 1112 may be omitted. The following sections provide further explanation regarding each of the 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 generally be addressed to the clinician server 200b, the web portal 150, the connection server 118, and / or the system hub 120. Messages may be internally routed to different modules 1102 - 1112 based on content and / or identifiers. For example, the application 1002 may provide an identifier in the header to specify the module 1102 - 1112 to which a message is to be received. For text - based messages, the router in the clinician server 200b may determine the destination module 1102 - 1112 based on the message content or previous messages. 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 transmits the received message for processing via the data acquisition module 1104.

[0197] (A. Registration Module Embodiments) The exemplary registration module 1102 is configured to register the personal mobile communication device 200a and / or the home therapy machine 90 with the clinician server 200b and / or in the patient medical records stored in the database 1010. The exemplary 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 presented 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 obtained based on the registration information.

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

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

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

[0201] The data access module 1106 can also be configured to display information differently from the patient's medical records 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 can render the data in a photograph transmitted to the personal mobile communication device 200a via text for viewing. Additionally, or alternatively, the data access module 1106 can transmit the stored medical record information as text to the personal mobile communication device 200a. Thus, even if the application 1002 is not installed, the application 1020 in the clinician server 200b is configured to provide the patient with access to data using the native application on the personal mobile communication device 200a.

[0202] FIG. 12 shows a schematic diagram illustrating communication between a home therapy machine 90 of FIGS. 10 and 11, a personal mobile communication device 200a, and a clinician server 200b, according to an exemplary embodiment of the present disclosure. First, the home therapy machine 90 is registered with the clinician server 200b via the registration module 1102 of 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 connection 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 was originally generated and stored in the clinician server 200b and provided to the patient when the patient receives the home therapy machine 90. The PAC may include a patient identifier or other code unique to the patient. The registration module 1102 in the clinician server 200b stores the generated PAC in one or more patient records and / or registration files associated with the patient. After entering the PAC, the home therapy machine 90 generates and transmits a message 1202 that includes the PAC. The message may also include the hardware identifier of the home therapy machine 90 and / or the IP address assigned to the home therapy machine 90. The home therapy machine 90 transmits the message 1202 to a pre-programmed address, in this case, the connection server 118. The exemplary connection server 118 relays the message 1202 to the system hub 120, and the system hub 120 routes the message to the clinician server 200b. The registration module 1102 in the clinician server 200b uses the PAC to register the home therapy machine 90 with the patient. Registration includes, for example, associating an identifier of the home therapy machine 90 with the patient's medical record. Registration may also include the clinician server 200b storing the IP address of the home therapy machine 90 and enabling messages to be transmitted to the home therapy machine 90. After registration, the data acquisition module 1104 of 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 can download the application 1002 or otherwise receive it via one or more messages 1204 from the clinician server 200b (or a third-party application store). In certain embodiments, during registration of the home therapy machine 90, the patient (or clinician) may provide the phone number of 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 attached file that, when executed, installs the application 1002 on the personal mobile communication device 200a. Instead of providing the phone number, the patient may alternatively provide an email address during registration of the home therapy machine 90. Thus, the message 1204 includes 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 enable the patient to register in two different ways according to the capabilities and / or personal preferences of their personal mobile communication device 200a. If the patient desires to register their personal mobile communication device 200a as a device with fewer features, message 1204 includes text that prompts the patient to respond to that text. The reply to message 1204 is provided via text message 1206, which is routed to registration module 1102. In turn, registration module 1102 registers personal mobile communication device 200a with an indication that application 1002 is not installed. In some cases, message 1204 may also include text or a hyperlink that prompts the patient to select a hyperlink 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, registration module 1102 registers personal mobile communication device 200a based on information provided by the patient and / or information read from personal mobile communication device 200a.

[0206] After the application 1002 is installed, the patient may register the personal mobile communication device 200a. In certain embodiments, 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 message 1206 to the system hub 120 for routing to the clinician server 200b. The message 1206 may also include device type information of the personal mobile communication device 200a (as determined by the application 1002).

[0207] In some cases, the application 1002 may be configured with the destination address of the web portal 150, and the destination address 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 at the clinician server 200b. In still other cases, the application 1002 transmits the message 1206 to the web portal 150 as one or more text messages or email messages (the web portal 150 is assigned a phone number, IP address, email address, or other address). The exemplary registration module 1102 uses the PAC within the message 1206 to register the personal mobile communication device 200a in the medical records and / or registration files stored in the database 1010. At this point, both the home therapy machine 90 and the personal mobile communication device 200a are registered to the same patient at 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 a text message or through a web browser. Thus, the registration module 1102 of the clinician server 200b may transmit a text message with a hyperlink to a database or web page for completing the registration to the personal mobile communication device 200a. Alternatively, the text message may include a prompt for the patient to respond with their PAC. Providing the PAC via any of these registration processes enables 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 communication device 200a, and the clinician server 200b. During operation, the home therapy machine 90 generates treatment information and status information (e.g., medical information). As discussed above in connection with FIGS. 1-9, the treatment information includes the volume of fluid infused, the amount of ultrafiltration ("UF") removed from the patient, and / or the treatment time. The status information includes alarms, alerts, or diagnostic information. Before or after treatment, the home therapy machine 90 generates one or more messages 1208 with medical information, which are transmitted to the connection server 118. In turn, the connection server 118 routes the message 1208 to the system hub 120, which routes the message 1208 to the data acquisition module 1104 of the clinician server 200b. After reception, 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 find the appropriate medical record in the database 1010.

[0210] The exemplary home therapy machine 90 may be configured to encode, label, or otherwise identify the transmitted medical information using metadata or other data identification techniques. Encoding or labeling enables the data acquisition module 1104 (or the interface in 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 encoding or labeling may be stored in the record, which is later used to search for and display the medical information.

[0211] FIG. 12 illustrates a personal mobile communication device 200a transmitting medical information or medical information to a clinician server 200b. As will be described in more detail below, the personal mobile communication device 200a is configured to obtain medical information from medical devices including devices 90, 104, and 106. Obtaining medical information can include receiving information manually entered by a patient via a wired or wireless connection and / or processing images recorded by a camera 1004 of the personal mobile communication device 200a. The obtained medical information is packaged into one or more messages 1210 and transmitted by the personal mobile communication device 200a to a web portal 150. The message 1210 can be a text message, an email message, or a web-based message (e.g., an HTTP message, an Extensible Markup Language ("XML") message, a JavaScript Object Notation ("JSON") payload, etc.). In some embodiments, the personal mobile communication device 200a can format the obtained medical information into one or more data fields prior to transmission. Generally, the medical information obtained at the personal mobile communication device 200a is less structured than the medical information generated by the home therapy machine 90. Thus, the personal mobile communication device 200a and / or a data acquisition module of the clinician server 200b performs at least some processing of the medical information to provide an appropriate context or structure for inclusion in the patient medical record. Examples of the processing performed are described in more detail below.

[0212] FIG. 13 illustrates an exemplary patient data structure 1300 stored on the clinician database 1010 of FIG. 10 according to an exemplary embodiment of the present disclosure. The patient data structure 1300 includes separate patient records for different patients. In the illustrated example, the data structure 1300 includes a patient medical record 1302 for a patient associated with 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] As shown in FIG. 13, each of the medical records 1302 and 1304 includes data fields that identify the patient, the personal mobile communication device 200a, and the home therapy machine 90. For example, the records 1302 and 1304 include data fields regarding a patient identifier, the type of the personal mobile communication device 200a, the type of the home therapy machine 90, and a home therapy machine identifier (received via registration). The patient identifier may correspond to the PAC assigned to the patient. The records 1302 and 1304 may include additional fields regarding the patient's name, address, gender, date of birth, etc. The records 1302 and 1304 may further include fields regarding the network address of the personal mobile communication 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 the treatment information and medical information should be presented and / or transmitted to the personal mobile communication device 200a.

[0214] Also, as shown in FIG. 13, medical records 1302 and 1304 include fields related to treatment and medical information. The data acquisition module 1104 stores the treatment information received from each home therapy machine 90 in records 1302 and 1304. In addition, the data acquisition module 1104 stores the medical information received from each personal mobile communication device 200a in records 1302 and 1304. In some embodiments, the data fields are further divided into individual fields regarding data types. For example, records 1302 and 1304 may include treatment information fields regarding the volume of fluid infused, the amount of ultrafiltration ("UF") removed from the patient, and / or the treatment time. Records 1302 and 1304 may also include data fields regarding alerts or alarms generated during treatment and / or alerts or alarms determined at the clinician server 200b based on 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 treatment and / or medical device may be compiled by treatment, the date / time generated, and / or the date / time received. In some embodiments, 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. Further, the communications may include information related to requests to change or modify the treatment from the personal mobile communication device 200a and / or the clinician device 152. Generally, medical records 1302 and 1304 are configured to store information for improving the patient's involvement 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, the treatment information received from the home therapy machine 90 is generally structured. In other words, the home therapy machine 90 is configured to transmit treatment information that is formatted for direct input into one or more data fields of a patient's medical record. In some embodiments, the home therapy machine 90 formats a message (or otherwise accesses one or more APIs) for transmission through the API of the data acquisition module 1104 for input of treatment information into the appropriate data fields. In contrast, the medical information recorded by the patient's personal mobile communication device 200a may not initially be structured for inclusion in the patient's medical record. As will be 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 input into the medical record.

[0217] (1. Embodiment of Manual Input of Medical Information into the Application) To receive structured information, in some embodiments, the exemplary application 1002 of the personal mobile communication device 200a is configured to display a prompt indicating the medical information required for input into the patient medical record by the patient. The exemplary application 1002 may include a routine or algorithm that defines the fields to be displayed to prompt the patient for medical information. In some embodiments, the fields or the screen on which the fields are displayed are arranged and / or ordered in relation to a medical fluid delivery treatment. The display of the fields informs the patient regarding the medical information required for the patient record.

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

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

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

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

[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 cause the application 1002 to display text input features for selecting each data field 1402, 1404, or 1406 and entering a value. User interface 1400 includes a field 1408 that enables the patient to specify whether the blood pressure measurement was performed in a standing position or a sitting position. Further, user interface 1400 includes a data field 1410 that enables the user to specify the date / time on which 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 the systolic blood pressure data field 1402, which causes the application 1002 to display a tutorial that instructs the patient on how to perform a blood pressure measurement and identify the systolic blood pressure measurement value. The tutorial may include text, text / photo, audio recording, animation, and / or video. The tutorial may be stored locally as part of the application 1002, or may be stored on the clinician server 200b for remote access or streaming.

[0224] User interface 1500 of FIG. 15 is configured to be displayed by application 1002 when the patient is scheduled to perform manual exchange therapy and / or when the home therapy machine 90 is not registered with the clinician server 200b. Manual renal failure exchange therapy requires the patient to do everything, without the assistance of the machine, to connect a container of dialysis fluid to his or her abdomen for a dwell duration before the spent dialysis fluid can be drained. For manual therapy, the patient needs to enter his or her manual exchange medical information in order to enable his or her records to reflect accurate treatment information.

[0225] The exemplary application 1002 can 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 can transmit a message to the application 1002 indicating whether the home therapy machine 90 has been registered. If the home therapy machine is not registered, the application 1002 can be configured to display the user interface 1500 and / or other user interfaces to obtain the treatment information that can normally be transmitted by the home therapy machine 90.

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

[0227] Instead of displaying user interfaces 1400 and 1500 at a designed time, application 1002 may instead cause an alarm to be displayed on personal mobile communication device 200a. The alarm may identify the medical information required or may 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 the icon for application 1002 on the home screen of personal mobile communication device 200a. In still other embodiments, application 1002 may not notify the patient about the medical information required. Instead, application 1002 may enable the patient to navigate to a desired user interface for entering medical device data and / or treatment information.

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

[0229] After medical information is input by a 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 input into the patient's medical record. Application 1002 is configured to transmit the medical information after the patient has entered it into a data field within the user interface or otherwise pressed a send button on the interface. In other instances, application 1002 may transmit the medical information at a predetermined time such as before or after treatment.

[0230] (2. Wireless Input Embodiment of Medical Information into the Application) In some embodiments, the patient may choose to wirelessly input medical information on their personal mobile communication device 200a. The medical information may be received on 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 instances, 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 connection application (e.g., an NFC application) that wirelessly reads medical information from the medical device.

[0231] In one example, a patient may pair his or her 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 the 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 the systolic blood pressure, which causes the systolic blood pressure value to be entered 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 has been selected by the patient. The application 1002 may use data labels or metadata to determine which fields 1402-1410 the medical information from the blood pressure monitor 104 should be entered into.

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

[0233] (3. Image Input Embodiment of Medical Information into the Application) The exemplary application 1002 on the personal mobile communication device 200a is configured to enable a patient to input medical information and / or treatment information by recording an image of a medical device or the screen of a medical device. The personal mobile communication device 200a uses the 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 entered into one or more data fields of the user interface of the application 1002. The use of images can reduce data entry errors from patients or clinicians.

[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. Otherwise, simply using the OCR feature makes all of the displayed text selectable. Thus, the patient still has the need to copy and paste the text from the image into the data field. In comparison, rules or data templates can classify or identify text from an image as fields, which enables easy or automatic selection by the patient for entry into the data fields of the user interface.

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

[0236] A data template defines or specifies data fields for certain medical information included within an image. Generally, the image includes extracted text with medical information. In some cases, all of the extracted medical information may not be required or necessary. Instead, only certain medical information within the recorded image is required for input into data fields of a user interface or the patient's medical record. Related medical information or relevant medical information refers to medical device data or medical information that is identified or selected for input into data fields of the user interface of Application 1002 or, more generally, for input into the patient's medical record.

[0237] FIG. 16 illustrates a schematic diagram of a personal mobile communication device 200a for recording and processing images for medical information extraction according to an exemplary embodiment of the present disclosure. The illustration of the personal mobile communication device 200a is exemplary, and some of the blocks may be combined, further divided, or removed. Additionally, in some embodiments, the personal mobile communication device 200a may include additional blocks such as a memory 1018 that stores instructions that, when executed by a data processor 1602 (or more generally, a processor 1016), cause the application 1002 to process an image 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 includes displaying one or more camera messages via the screen 1002, where the camera messages provide information that prompts a clinician or patient (e.g., an operator) to record a particular image. Alternatively, after the patient selects to enter medical information into one or more data fields of the application 1002 using an image input method, the data processor 1602 may initiate an image processing mode. After the selection of the image input method, the data processor 1602 is configured to obtain one or more images.

[0239] In some embodiments, the data processor 1602 causes the personal mobile communication device 200a to open a camera application and enables the patient to record one or more images. The patient may further select the recorded images to be processed or discarded. The selected images are analyzed to identify text (as medical information) for potential entry into the data fields of 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 data fields selected by the patient. For example, the data processor 1602 may execute a blood pressure workflow to obtain 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 that identifies a medical device to be recorded, a 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 that defines a user interface window of the medical device for imaging. Further, the data processor 1602 may display a reminder message if an image is not recorded within a predetermined period (e.g., 5 minutes). The message may include text that provides instructions and / or text that identifies the intended target for imaging. The message may also include instructions regarding how to navigate to a user interface window of the medical device using a control interface of the medical device. The message may further include graphical elements such as an illustration of the medical device, a consumable item, the identifier 1012, and / or the user interface window for which the image is to be recorded.

[0242] In some embodiments, it should be understood that the data processor 1602 does not display messages. Instead, the data processor 1602 responds to images recorded by a 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 that prompts the clinician via the application 1002 to identify the medical device on which the image was recorded. The prompt may include a pull-down menu of available or common medical devices. In other examples, the data processor 1602 automatically identifies medical information using one or more data templates or data markers to determine the extracted medical information to be entered or written into a user interface or data field of a medical record.

[0243] To record an image, the exemplary data processor 1602 and image processor 1604 (more generally, processor 1016) provide operations for the application 1002 associated with the camera 1004. The patient provides an indication via the camera user interface 1606 (e.g., a touch screen or buttons on the personal mobile communication device 200a) to record an image. The patient actuates 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 indication and instructs the camera 1004 to record the 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 communication device 200a.

[0244] In some embodiments, data processor 1602 may cause a ghost image depicting an image to be recorded to appear on display interface 1022. The ghost image is provided over a stream of images provided by camera 1004 in preview mode. The purpose of the ghost image is to provide assistance to the clinician or patient in verifying that the image to be recorded contains the desired medical information and is recorded at an appropriate distance. For example, data processor 1602 may display a ghost image of a given identifier on a given medical device. The patient aligns personal mobile communication device 200a such that the stream of images of identifier 1012a is positioned to be aligned with the ghost image. The patient may then record an image of identifier 1012a. In some cases, data processor 1602 uses image analysis to determine a difference between the ghost image and the stream of images. Data processor 1602 may cause an instruction to be displayed that prompts the patient to move personal mobile communication device 200a in a direction to reduce the determined difference. Data processor 1602 determines when the difference falls below a certain threshold and may indicate that the image is aligned. When the image is substantially aligned, data processor 1602 may provide a graphical indication on display interface 1022 that the image may be recorded or may cause the image to be automatically recorded without input from the patient.

[0245] Data processor 1602 may provide a prompt asking the patient to accept an image. After receiving an acceptance instruction via camera user interface 1606, image processor 1604 may analyze the image to identify or otherwise extract text. In some cases, data processor 1602 may not prompt the clinician to accept an image. Instead, the patient may provide an instruction via camera user interface 1606 to delete an image. Image processor 1604 performs analysis to identify text until the image is deleted.

[0246] To identify text, the image processor 1604 uses, 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 use image analysis to identify patients, medical devices, and / or consumable items. For example, the image processor 1604 may access a library of medical device images to identify medical devices within the image. In this example, the image processor 104 may use an image matching routine to determine a match. Such a comparison may be made instead of a medical device having an identifier 1012. The image processor 1604 may use a similar routine and / or algorithm for identifying the consumable item 1006.

[0248] The exemplary data processor 1602 is configured to decode the identifier 1012 and determine the type of medical device of the consumable item. Decoding may include relating the positions and thicknesses of lines and / or rectangles to each other in associated medical information. The coded lines and rectangles may correspond to a sequence of characters and / or numbers. For example, the data processor 1602 may use the lines or rectangles of the identifier 1012 to determine the device model number, medical device type, asset code, etc. The decoded identifier 1012 may provide associated medical information for input to 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 an image from a medical device or consumable and / or to determine a data template.

[0249] The exemplary image processor 1604 of FIG. 16 transmits an image with text and / or medical information that has been extracted or otherwise identified to the data processor 1602. The exemplary data processor 1602 uses one or more data templates from the data template database 1608, for example, to identify associated 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 data templates.

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

[0251] The data template 1700 is stored within a database 1608 along with a plurality of other data templates regarding different types and / or models of medical devices and / or consumable items. After receiving an identifier 1012 of a medical device (or a specification of a medical device or data field by a patient), the image processor 1604 selects the corresponding data template 1700. Additionally, or alternatively, the image processor 1604 may use image processing to select a data template that best matches the recorded image, e.g., using information labels or text positions.

[0252] The exemplary data template 1700 of FIG. 17 includes device data (or text) fields 1702, 1704, 1706, and 1708, which define where certain medical information is located on a particular user interface window of a medical device. In some examples, the data template 1700 is graphical, such that image analysis is performed to align the fields 1702 - 1708 with the extracted text in the image. In other examples, the data template 1700 includes a file (or other data structure) having coordinates or positions 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 locations within the data template 1700. In some examples, the image processor 1604 may scale the image to match the size or coordinate space of the data template 1700.

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

[0254] The match between the label texts including the label text for the unrelated device data field can be used to confirm that the image is from the correct window or screen of the medical device. For example, the image processor 1604 can match the label text "ultrafiltration window" to the corresponding extracted text at a relatively same location in the recorded image. The match confirms that the image was recorded from the ultrafiltration window of the medical device for treating renal insufficiency. However, the extracted text is not the relevant medical information regarding the patient's medical record. If the label text does not match the extracted text, the image processor 1604 can display a message prompting the patient to record an image of the ultrafiltration window of the medical device for treating renal insufficiency.

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

[0256] The exemplary device data fields 1704a and 1704b of FIG. 17 are used by the application 1002 to identify relevant medical information. In some cases, the application 1002 may display a flag or metadata indicating that the device data fields 1704a and 1704b are related to the selected data fields of the 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 related. In the example illustrated in FIG. 17, the image processor 1604 uses the label text of the data field 1704a to find the corresponding extracted text in the image. The image processor 1604 then uses the positional relationship between the device data fields 1704a and 1704b, or between the text value markers, to identify the extracted medical information from the image corresponding to the numerical value of the filtration volume limit. The image processor 1604 copies the extracted medical information related to the field 1704b from the image for input into, for example, the systolic blood pressure data field 1402 of FIG. 14.

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

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

[0259] In other embodiments, the data processor 1602 is configured to select one or more fields of the data template and prompt the patient to enter data into one or more data fields of the user interface of the application 1002. FIG. 18 shows a schematic diagram illustrating a patient entering data into the 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 a personal mobile communication device 200a. To enter medical information into the data fields 1402 - 1406, the patient selects each of the data fields either sequentially or together. For each selection, the application 1002 displays a prompt asking the patient how the data should be entered. After the patient selects the photo input method, the application 1002 opens the camera application and enables the patient to use the personal mobile communication device 200a to record an image 1800 of the screen of the blood pressure monitor 104. In some embodiments, 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 corresponding to the extracted text. In some embodiments, the application 1002 matches the location of text and / or labels in the image to the text and / or label locations in the data template to find a matching data template. In other examples, the patient may define the instructions of the blood pressure monitor 104, which enables the application 1002 to find the corresponding data template 1801. In still other examples, the application 1002 may first prompt the patient to record an image of the identifier 1012a of the blood pressure monitor 104. The data from the identifier is used by the application 1002 to select a data template. Regardless of how the data template 1801 is identified, the application 1002 applies the data template 1801 to the extracted text in the image 1800. This process includes the application 1002 identifying groups or fields of similar text. In some cases, the application 1002 may identify groups or fields of similar text based on the spacing between characters and / or words.

[0261] In the example illustrated in FIG. 18, application 1002 provides fields 1802, 1804a, 1804b, 1806, 1808, and 1810 for different sets of text. The patient selects the field into which data should be entered into the selected data field of user interface 1400. For example, to enter data into the 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 rules that specify that only integer numerical values can be received. Application 1002 reads the text for an integer numerical value (i.e., "145") from the selected field 1804a. Application 1002 then enters the identified integer numerical value into the systolic blood pressure data field 1402. The patient may continue for other fields 1404 - 1410 of user interface 1400 using 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 application 1002 or determined by the patient), application 1002 enables the patient to record and view multiple images. Application 1002 applies the appropriate data template to each of the recorded images. Application 1002 thus enables the patient to use one or more recorded images to enter information into user interface 1400 as if the patient were entering the values manually.

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

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

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

[0265] Before block 1906, the patient uses application 1002 to select data fields and select that medical information should be provided via photo input. In block 1906, the personal mobile communication device 200a records an image 1907 of a medical device, a consumable, the patient, etc. The image may include an identifier and / or a screen of the medical device. The personal mobile communication device 200a then determines or identifies the 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 a QR code (registered trademark), the personal mobile communication device 200a decodes the barcode and / or the QR code (registered trademark). The captured or encoded data is converted to text or American Standard Code for Information Interchange (「ASCII」) characters. In some embodiments, the personal mobile communication device 200a may also determine a data field for the identified text (block 1910). The data field may be determined, for example, using a data template. As described above in connection with FIGS. 17 and 18, the data template may define the location of a piece of text and / or define a label for a piece of text used to operably place a data field over the identified text within the recorded image. In some cases, the data field and / or the data template may be selected by the patient and / or determined from the identifier 1012 of the medical device. Alternatively, instead of using a template, procedure 1900 may instead provide an indication that the most recently recorded image has relevant medical information for extraction, selection, and / or transfer.

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

[0267] As determined in decision block 1912, if no additional images are required, the patient begins the process of entering medical information related to the data fields of the user interface. The process in the illustrated embodiment includes enabling the patient to select an image to which the relevant medical information is to be transferred. The selection of an image causes the personal mobile communication device 200a to display the image on the display interface 1022 (block 1914). It should be understood that the selected image includes the 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 where the data is to be entered.

[0268] The personal mobile communication device 200a receives a selection of relevant medical information and / or a data field with associated medical information for entry into a designed data field of the user interface of application 1002. The selection can be made by the patient pressing an area of the touch screen 1002 of the personal mobile communication device 200a corresponding to the medical information to be entered. The selection of relevant medical information and / or field causes, in some embodiments, at least a portion of the selected text to be automatically entered into the personal mobile communication device 200a (block 1916).

[0269] After the selected text is entered, the personal mobile communication device 200a determines whether additional relevant medical information should be entered based on a selection of an additional data field of the user interface (decision block 1918). In some examples, the personal mobile communication device 200a operates a sequence or routine that provides a prompt for the patient to select appropriate text and / or an image for entry into the data field. If additional relevant medical information exists as determined at decision block 1918, procedure 1900 returns to blocks 1914 - 1916 and the patient defines an image and / or relevant medical information for data field entry. If no additional relevant medical information for entry exists as determined at decision block 1918, exemplary procedure 1900 ends.

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

[0271] The exemplary application 1002 on the personal mobile communication device 200a is configured to receive images and / or text provided by a patient. In some embodiments, the application 1002 is configured to enable a patient to select a text or photo input. If the patient selects a text input, 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 within one or more messages to the clinician server 200b. The application 1020 in the clinician server 200b determines the appropriate patient medical record in the database 1010 and finds a "note" or free text field. The application 1020 stores the text provided by the patient in the field. In some cases, the application 1020 may also include a time / date stamp with the entered text. This information provides the clinician with additional information from the patient, including feedback regarding treatment.

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

[0273] (5. Manual / Wireless / Image Input Embodiments of Medical Information via Text) In some embodiments, the personal mobile communication device 200a of FIGS. 10 - 12 may not be able to install or operate the application 1002, or the patient may decide not to install the application 1002. However, the clinician server 200b still registers the personal mobile communication device 200a during the registration process. 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 the patient for medical information or otherwise obtain it 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 the application 1002 is not installed by reading the patient's registration file and / or medical record.

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

[0275] The exemplary data acquisition module 1104 of FIG. 11 is configured to format or otherwise structure the received information for input into one or more data fields of a patient's medical record. Generally, medical information received from a text message is unstructured. In other words, a text message does not provide an explicit correlation or reference to the designed fields of a patient's medical record. Instead, the data acquisition module 1104 is configured to determine the appropriate fields 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 fields. For example, a patient may send a message that includes 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 the character string) to field data labels, keywords, and / or metadata. If at least some of the words match, the data acquisition module 1104 is configured to identify a numerical value within the content of the text message and write the identified numerical value into the data field of the patient's medical record corresponding to the matching text. In some embodiments, the data acquisition module 1104 may compare the value to the acceptable range of the value before writing the value. If the value is outside the acceptable range, the data acquisition module 1104 may transmit a message indicating an error or a message prompting the patient to re-enter the value to the personal mobile communication device 200a.

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

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

[0279] Instead of receiving messages with text, data acquisition module 1104 may also receive messages with photo attachments. Similar to the processes described above in connection with FIGS. 16 - 19, data acquisition module 1104 is configured to process images, extract text, and identify relevant medical device data regarding one or more data fields of a medical record. Further, the above disclosure describes the use of text messages, but 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 messages, social media posts, etc.

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

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

[0282] In other embodiments, it should be understood that the patient medical template 2100 may include additional or fewer fields. For example, the template 2100 may additionally include data fields regarding pre-treatment patient weight and post-treatment patient weight, patient glucose levels, and / or patient date of birth. In another example, the template 2100 may include fill rate, dwell time, drain or fluid removal rate, blood flow rate, effluent volume, 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, signs of excessive patient fluid, filtration rate, remaining time, dialysate concentration, dialysate name, patient identifier, room identifier, treatment area identifier, a timestamp indicating when the data was generated, alarm conditions, alert conditions, and / or fields regarding 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 to the data acquisition module 1104 that includes the text "manual exchange". In response, the data acquisition module 1104 identifies and selects the template 2100 regarding manual exchange. In another example, the patient may send a message to the data acquisition module 1104 that includes the text "before treatment" or "start treatment" via the personal mobile communication device 200a. In response, the data acquisition module 1104 identifies and selects a template for obtaining the medical information required before treatment is initiated.

[0284] In the example illustrated in FIG. 21, the exemplary data fields include a field 2102 for the patient's name, a field 2104 for the patient identifier, a field 2106 for the patient's weight, a field 2108 for the patient's blood pressure, a field 2110 for the date of treatment, a field 2112 for the amount of UF removed, a field 2114 for the total fluid volume provided to the patient, a field 2116 for the glucose level, a field 2118 for the treatment prescription identifier, and a field 2120 for the disposable cassette identifier. In the case where the renal therapy machine 90 is registered with the clinician server 200b, the data acquisition module 1104 may remove at least fields 2112 - 2120 (or select a separate template with fields 2112 - 2120 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. Further, the template 2100 may omit fields 2102 and 2104 based on at least a portion of the patient information already registered.

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

[0286] The patient medical template 2100 illustrated in FIG. 21 is stored on the clinician database 1010 and is configured to be accessed by the clinician server 200b illustrated in FIGS. 10 and 11. When receiving a request to input data into the template regarding a patient, the clinician server 200b is configured to copy the template 2100 or create an instance thereof. The medical information received from the personal mobile communication device 200a is input by the data acquisition module 1104 into the appropriate data fields 2102 - 2120 of the copy or instance of the template 2100. When completed, the copy or instance is stored in the repository of the clinician database 1010 as the patient's medical record.

[0287] In some embodiments, the data acquisition module 1104 operates the routine 2150 in conjunction with or in place of the exemplary patient medical template 2100. In some embodiments, the routine 2150 can be programmed as metadata or computer-executable code regarding each of the data fields 2102 - 2120. In other examples, the routine 2150 can be stored in the clinician database 1010 in relation to the patient medical template 2100. Further, in these other examples, the 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 the 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 a data template related to the corresponding routine module 2152 - 2164 when a patient provides an image and / or text in a message. For example, while executing the routine module 2156 related to blood pressure, the data acquisition module 1104 transmits a message that prompts the personal mobile communication device 200a regarding "systolic blood pressure measurement". The patient responds with a text message that includes an image of the blood pressure monitor 104 screen or dial. The data acquisition module 1104 is configured to access a data template corresponding to or referenced by the routine module 1156 related to blood pressure measurement. The data acquisition module 1104 then applies the data template and uses the procedures described above in relation to FIGS. 16 - 19 to extract text from the image and identify the relevant systolic blood pressure medical information for input into the blood pressure data field 2108 of the template 2100.

[0289] The exemplary routine 2150 can be configured to be initiated based on one or more messages received by the data acquisition module 1104 upon request from a patient. For example, the data acquisition module 1104 can receive a message with text including "start", "begin", and / or "before treatment". The 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 with data. In other examples, the data acquisition module 1104 transmits a first message defined by the routine 2150 to the patient at a predetermined time for the treatment. After receiving a response message with appropriate medical information from the personal mobile communication device 200a, the data acquisition module 1104 continuously transmits the messages defined by the routine 2150. Thus, 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 communication device 200a (and the medical information is populated in the designated data fields 2102 - 2120 of the template 2100).

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

[0291] The weight scale module 2154 may include the identifier 1012c of the scale 106 in FIG. 10 and metadata or pre-formatted messages that instruct the patient to record an image of the screen. The weight scale module 2154 may also include character verification checks 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 weight scale module 2154 may use the medical information from the identifier 1012c to confirm that the medical information from the screen of the scale 106 is patient weight medical information. In other cases, the medical information from the identifier 1012c is used, for example, to select a data template based on the model or type of the scale 106. The data template is used by the data acquisition module 1104 to identify relevant weight scale medical information extracted from an image of the screen of the scale 106.

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

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

[0294] When medical information is received using routine 2150, the data acquisition module 1104 of application 1020 uses data validation checks to ensure that the data is within an acceptable range, is correctly formatted, and / or is in appropriate units. In some cases, 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 each field of template 2100 and / or the patient's medical record. When the data is in the appropriate format and units, the data acquisition module 1104 writes the medical information to each field of template 2100 and / or the patient's medical record.

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

[0296] To populate the data fields, the data acquisition module 1104 may, in some embodiments, read the names (and any corresponding metadata) of the data fields 2102-2120, create a message that prompts for a recording of an image, and send it to the patient. In one example, the weight data field 2106 includes metadata that identifies a 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 that instructs the patient of the personal mobile communication device 200a to record an image of the scale's screen. In the illustrated embodiment, the data acquisition module 1104 proceeds continuously through the template 2100 (or the patient's medical record), searches for blank data fields, and may request medical information from the patient via a message displayed by the personal mobile communication device 200a as appropriate. Alternatively, the data acquisition module 1104 may proceed through the template 2100 according to a predetermined order or sequence. For example, the data acquisition module 1104 may first search the data fields associated with the patient's wristband, and subsequently search the data fields regarding the scale medical device, the blood pressure medical device, and the renal failure treatment medical device.

[0297] FIG. 22 is a schematic diagram of the data acquisition module 1104 of the clinician server 200b of FIG. 11, according to an exemplary embodiment of the present disclosure. The illustration of the data acquisition module 1104 is exemplary, and it should be understood 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 (more generally, the clinician server 200b) includes an interface 2202 that provides connectivity with the personal mobile communication device 200a. The interface 2202 can include, for example, an Internet port or connection. In one embodiment, the interface 2202 is configured to receive messages from the personal mobile communication device 200a and convert them to a compatible format for internal processing. For example, the interface 2202 can convert SMS or text messages to the 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 can encrypt messages for transmission and / or decrypt received messages.

[0299] The exemplary data acquisition module 1104 includes a template processor 2204 configured to manage the writing or input of medical information from the personal mobile communication device 200a to 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) is used by the template processor 2204 to operate a routine (e.g., routine 2150) to obtain medical information from the personal mobile communication device 200a if available or as configured.

[0300] The exemplary template processor 2204 is configured to identify messages from modules of a routine (e.g., routine 2150) for transmission to the personal mobile communication device 200a. In some instances, the messages can be transmitted in a predetermined sequence to instruct or guide a clinician or patient through a process for populating a patient medical template with data. For example, the template processor 2204 can 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 meter 106 should be transmitted. The template processor 2204 can be configured to wait until medical information related to the identifier 1012c is received (for population of data field 2106 of FIG. 21) before identifying the message from routine module 2156 to be transmitted. In other instances, 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 can receive medical information associated with the identifier 1012c of the scale 106. In response to the received medical information, the template processor 2204 can determine that module 2154 corresponds to the received data and, accordingly, select a message prompting the patient to record an image of the screen of the 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 meter 106.

[0301] In addition to sending a message, the template processor 2204 may be configured to select a data template. The data template is stored in a data template database 2208 in the illustrated embodiment. 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 the medical device type to the template processor 2204 via a message. Further, as discussed above, the template processor 2204 may receive an image from the personal mobile communication device 200a, extract text from the image, and select an appropriate data template from the database 2208 to identify relevant medical information from the image, as described above.

[0302] In some embodiments, the template processor 2204 may receive from the personal mobile communication device 200a a stream of messages that include the patient medical template 2100 or substantially all of the medical information for the patient's medical record. In these embodiments, the template processor 2204 reads the labels, 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 entered or written. The template processor 2204 matches, for example, the metadata or information of the module (or the data fields 2102 - 2120 themselves) with the labels, metadata, and / or device data field information provided with the medical information to determine the appropriate data fields of the template 2100.

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

[0304] FIGS. 23 and 24 are flow diagrams of exemplary procedures 2300 and 2350 for entering data into the medical device template 2100 of FIG. 21 using images (and / or text messages received therefrom) recorded by the personal mobile communication device 200a of FIGS. 10-12 and 22, according to certain exemplary embodiments of the present disclosure. Procedures 2300 and 2350 are described with reference to the flow diagrams illustrated in FIGS. 23 and 24, but it should be understood that many other ways of performing the steps associated with procedures 2300 and 2350 may also be used. For example, the order of many of the blocks may be changed, some blocks may be combined with other blocks, and many of the blocks described 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 communication device 200a. Instead, in embodiments, the personal mobile communication device 200a may first obtain substantially all relevant medical information regarding the patient medical template and queue it up until (or intentionally) a connection to the clinician server 200b becomes available. The actions described in procedures 2300 and 2350 may be performed, for example, among a plurality of devices including the personal mobile communication device 200a and the clinician server 200b.

[0305] The exemplary procedure 2300 begins in FIG. 23 when the clinician server 200b of FIGS. 10 - 12 and 22 receives a message 2301 from the personal mobile communication device 200a (block 2302). The message 2301 indicates a treatment to be performed on a patient or a request to initiate transmission of medical information. The clinician server 200b then determines a patient medical template (e.g., the patient medical template 2100 of FIG. 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 provides only the completion of one type of template (e.g., a template regarding renal insufficiency therapy), the message 2301 may indicate a request to initiate the entry of a blank template. In response to the message 2301, the clinician server 200b creates a copy of the patient medical template for data entry.

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

[0307] The exemplary procedure 2300 continues in FIG. 24, and the clinician server 200b transmits a second camera message 2313 to the personal mobile communication device 200a (block 2314). The second camera message 2313 can be determined based on the type of medical device defined by the message 2307. Further, the second camera message 2313 can include information for displaying a certain window (or related medical information) on the medical device to record an image. After a while, the clinician server 200b receives a message 2315 including text or an image thereof from the window of the medical device (block 2316). The exemplary clinician server 200b uses the identified data template to extract related medical information from the image and determines or otherwise identifies the data fields of the patient medical template corresponding to the related medical information (block 2318). If the message 2315 includes text, the clinician server 200b determines or otherwise identifies the data fields of the patient medical template corresponding to the related medical information. The clinician server 200b then inputs the related received medical information into the determined and / or identified data fields of the template (block 2320).

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

[0309] The exemplary procedure 2350 begins in FIG. 23 by the personal mobile communication device 200a transmitting (2352) a message 2301 indicating a treatment to be performed on a 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. The 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, for example, specify that the identifier 1012 of the medical device is to be imaged. The personal mobile communication device 200a then records an image of the identifier 1012 of the medical device based on the input from the patient (block 2356). In some embodiments, the patient may enter text specifying the medical device type / model or select from a drop-down menu if the identifier is not available or if the patient does not desire (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 transmits the extracted medical information to the clinician server 200b in a message 2307. In some embodiments, the personal mobile communication device 200a transmits the recorded image within the message 2307 instead.

[0311] Thereafter, the personal mobile communication device 200a receives from the server 200b a camera message 2313 with information for prompting the patient to display a prompt for recording an image of the medical device's screen (or other defined area) (block 2360). In response, the personal mobile communication device 200a displays to the patient a prompt with the information required to image the medical device. In response to the prompt, the patient uses the personal mobile communication device 200a to record an image of the medical device's screen (or other defined area) (block 2362).

[0312] In FIG. 24, the exemplary 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 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 (decision block 2368) whether additional relevant medical information is required from the medical device associated with the extracted relevant medical information. The determination can 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 required, the exemplary personal mobile communication device 200a returns to block 2360 and processes the camera message 2313 for another window (or part of a medical device / consumable item) for which relevant medical information is required. However, if no additional medical information is required for the current medical device, the personal mobile communication device 200a determines (decision block 2370) whether medical information is required from another medical device (or consumable item 1006). If additional medical information is required, the personal mobile communication device 200a returns to block 2354 and processes the camera message 2305 to identify another medical device for imaging. If no additional medical information is required for completing the patient medical template, the exemplary personal mobile communication device 200a ends the session, thereby ending procedure 2350.

[0314] (6. Manual / Wireless / Image Medical Information Input via Web Browser or File Transfer) In some embodiments, the data acquisition module 1104 of FIG. 11 is configured to enable a patient to input medical information or provide an image using their personal mobile communication device 200a via a web browser or a file transfer program. The web browser or file transfer program enables the personal mobile communication device 200a to provide medical information and / or an image without using the application 1002. In this embodiment, the clinician server 200b hosts a website, an API, and / or a file transfer site to which an address or a Uniform Resource Locator (URL) is assigned. The web browser or file transfer program on the personal mobile communication device 200a is configured to access the hosted website, API, and / or file transfer site 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 is previously registered and provides access. In still other embodiments, the data acquisition module 1104 provides a mailbox or other interface (e.g., an API) for receiving medical information or an image without providing access by the personal mobile communication device 200a to a secure location.

[0316] When a patient obtains access via the personal mobile communication device 200a, in some embodiments, the data acquisition module 1104 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 FIGS. 14 and 15. Similar to the personal mobile communication device 200a that includes the application 1002, the clinician server 200b provides a user interface and data fields for receiving medical information. The data acquisition module 1104 may also enable the patient to select a data input method such as text or an image.

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

[0318] FIG. 25 shows a schematic diagram of a clinician server 200b that hosts a website or file transfer site for receiving medical information via an image 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 operating a web browser application 2500 directed to a website 2502 hosted by the clinician server 200b. The website 2502 includes a graphical user interface for 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, 804, 1806, 1808, and 1810. The patient selects fields 1802, 804, 1806, 1808, and 1810 where the text should be entered into one or more selected data fields of the website 2502. In this way, the clinician server 200b enables the patient to provide medical information via a website, file transfer program, or API.

[0319] (C. Data Access Module Embodiments) Turning back to FIG. 11, the exemplary data access module 1106 is configured to provide patients and clinicians with access to medical information stored within medical records in the clinician database 1010. As described above in connection with the data acquisition module 1104, different possible configurations of the personal mobile communication device 200a, whether or not the application 1002 is installed, exist. Based on the configuration, the data access module 1106 is configured to provide access or otherwise display the data. To determine the configuration being used by a particular patient, the exemplary data access module 1106 is configured to access a registration table or the patient's medical record to identify whether the 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 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-featured personal mobile communication device 200a. Based on the registration information, the data access module 1104 determines whether the application 1002 is operating on a feature-rich device or a less-featured 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 within a patient's medical record should be converted to a different format prior to transmission. For example, medical information and / or treatment information may be stored within the medical record in an HL7 format. However, this format may not be suitable for text messages and / or applications. The exemplary data access module 1106 determines the capabilities of the personal mobile communication device 200a to which the data is to be transmitted. The data access module 1106 determines the capabilities based on whether the application 1002 is installed and / or registration information indicating whether the personal mobile communication device 200a is a feature-rich device. To view medical information on the application 1002, the data access module 1106 uses one or more APIs to convert the medical information and / or treatment information from the HL7 format to, for example, a HyperText Markup Language ("HTML") format, a Java (registered trademark) Script Object Notation ("JSON") format, or an XML format (e.g., an application format). If the data access module 1106 determines that the application 1002 is not installed, the data access module 1106 converts the information from the HL7 format to, for example, a text message or SMS message format via one or more APIs. The exemplary data access module 1106 thus enables patient medical record information to be viewed by the patient regardless of the capabilities of their personal mobile communication device 200a.

[0322] (1. 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 the records of one or more patients for display in defined fields, graphs, etc. of one or more user interfaces provided by the application 1002. In some cases, the fields from the medical records are referenced to the fields of the user interface of the application 1002.

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

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

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

[0326] The exemplary user interface 2700 of FIG. 27 illustrates the average drain time for each UF exchange. The drain time is provided in graph 2702. Between user interfaces 2600 and 2700, a patient can gauge how the treatment is progressing over time. Any deviation in the treatment should be readily apparent and should help persuade the patient to adhere to the prescribed therapy.

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

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

[0329] (2. Information Display Embodiment via a 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 information and / or treatment information on one or more web pages, similar to the user interfaces 2600-2900 of FIGS. 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 medical information within the web page. The data access module 1106 may be configured to format or render the medical information and / or treatment information based on the web browser type and / or operating system of the personal mobile communication device 200a. In some cases, the data access module 1106 may request a username and password from the patient prior to providing access to the website.

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

[0331] In one example, data access module 1106 may receive a text message that includes the text "Send 7-day UF data". In response, data access module 1106 identifies a patient record corresponding to the phone number of the personal mobile communication device 200a on which the text message was received. Data access module 1106 may then use a lookup table or keyword search to identify fields within the patient's medical record that contain matching sets of characters or text related to the UF data (e.g., "7-day UF"). Data access module 1106 copies the matching text and creates a reply message with the value of UF for the previous 7 days, which is transmitted to personal mobile communication device 200a. Additionally, or alternatively, data access module 1106 creates and renders a 7-day graph similar to graph 2602 of FIG. 26. Data access module 1106 creates an image of the graph, which is transmitted to personal mobile communication device 200a as an image within the text message. The image may be stored as a file such as.jpeg,.gif,.png, etc. The patient of personal mobile communication device 200a may view the graph via the text message. Thus, exemplary 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, data access module 1106 determines the manner in which data should be transmitted based on the registration information provided by the patient and / or an indication of whether application 1002 is installed on the patient's personal mobile communication device 200a.

[0332] (4. Alarm / Alert Embodiment) In addition to providing the display of medical and / or treatment information, the exemplary data access module 1106 of FIG. 11 is configured to determine and / or generate alarms and / or alerts for patients and / or clinicians. The data access module 1106 may transmit the 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 defines the device to which a particular alarm / alert should be transmitted. A clinician may use the clinician device 152 to subscribe to a particular alarm / alert and / or patient.

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

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

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

[0337] In one example, an alarm and / or alert may be generated to indicate that the patient should select a different treatment program from a plurality of prescribed treatment programs or make an adjustment to the treatment program. In this example, an alarm or alert rule may specify that the data access module 1106 should calculate an accumulated fluid value and compare the patient's blood pressure or weight with respective change thresholds while comparing with a certain threshold. The accumulated fluid value can be determined from individual fluid fill and drain volumes, which indicates the fluid remaining in the patient's abdominal cavity. If the blood pressure or weight and the accumulated fluid value (or trend) are outside the 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 can respond via the application 1002 or a text message and cause the clinician server 200b to make appropriate changes to the patient's prescription or therapy program.

[0338] In some embodiments, an 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 a 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 additional weight or blood pressure measurements is sent to the patient's personal mobile communication device 200a. For example, an alarm or alert may define that when the blood pressure value (or trend) exceeds a predetermined threshold, a prompt for a new blood pressure measurement is required. In other examples, an alarm or alert may define that when the accumulated fluid value or the removed UF value (or trend) is outside the acceptable range, a prompt for a new blood pressure measurement is required. 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., the 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 the acceptable range, the data access module 1106 may escalate the alert to an alarm 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 boundary patient conditions for requesting additional information from the patient before determining whether further attention or action is required from the clinician or patient.

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

[0340] In another example, the data access module 1106 may include one or more rules that define that an alert should be generated in response to the treatment information being out of range. For example, a large difference between the fluid fill volume and the drain volume may indicate a leak in the dialysis tubing or the connection to the patient. In response, the data access module 1106 transmits to the patient an alert that prompts the patient to verify the fluid connection. 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 treatment cycle (or main sequence), or whether the tubing should be replaced. The data access module 1106 may determine similar consumable issues regarding the cassette, cartridge, etc., based on the treatment and / or medical information. For example, a low volume of UF removed may prompt the data access module 1106 to transmit an alert to verify the concentration of the dialysis fluid and / or concentrate to which the patient is connected on the home therapy machine 90.

[0341] (D. Treatment Control Module Embodiments) The exemplary treatment control module 1110 of FIG. 11 is configured to enable a patient and / or clinician to change a prescription and / or program on the home therapy machine 90. To operate, the home therapy machine 90 is assigned one or more prescriptions regarding the patient. The prescription may define the type of treatment (e.g., automated peritoneal dialysis treatment, manual exchange treatment, hemodialysis treatment, etc.), the period during which the patient should receive the treatment, the glucose level or other concentrate level of the treatment fluid, the amount of UF to be removed per day, and / or the number of times per day or the duration range for each treatment. Each prescription may include one or more programs. The program may define the treatment duration, the total volume of fluid to be provided to the patient, the number of fill, dwell, drain cycles to be repeated, and / or an indication of whether the treatment includes tidal therapy. Differences in the programs within a prescription enable a patient or clinician to change a certain treatment parameter based on the patient's condition or activity.

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

[0343] In some embodiments, the exemplary treatment control module 1110 operates in relation to the application 1002 on the personal mobile communication device 200a and / or the application on the clinician device 152, and is configured to enable a patient and / or a 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 enables a patient to select between three different programs, namely, a short-term program, a long-term program, and a weekend program. The patient can select a program based on his or her activities and / or situation. In some embodiments, the application 1002 can display an alert from the data access module 1106 that provides a recommendation to change the program based on a 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 indicating the selection to the treatment control module 1110. In response, the treatment control module 1110 updates the patient's medical record to reflect the changed program, including the time / date of the change. Further, the treatment control module 1110 transmits a message to the home therapy machine 90 providing instructions to change to the selected program. In some cases, the message may include treatment parameters regarding the newly selected program. The home therapy machine 90 then performs the next treatment accordingly, 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 operating according to the program.

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

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

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

[0348] In addition or alternatively, the treatment control module 1110 is configured to enable treatment changes via text messages. In one example, the patient may send a message from the personal mobile communication device 200a that includes the text "change treatment". In response, the treatment control module 1110 is configured to send a reply message with different treatment program options and the corresponding code or indicator next to each option. The patient may enter the indicator or code in the response message to select the desired program. In another example, the patient may send a message with text such as "long-term program" to cause the treatment control module 1110 to change the program to a long-term program.

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

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

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

[0352] Educational materials and / or incentives may be stored within 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 Cleveland Clinic®. The education module 1108 may include a rule data structure that defines the conditions under which certain educational materials and / or incentives should be provided to the personal mobile communication device 200a.

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

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

[0355] Exemplary education module 1108 may store in the patient's medical record any educational content or incentive instructions displayed by personal mobile communication device 200a. Such information may be useful to a clinician in determining how the patient is engaging in treatment. The stored information may also provide an indication of the patient's awareness of the treatment.

[0356] (F. Auxiliary Module Embodiments) The exemplary auxiliary module 1112 of FIG. 12 is configured to create a communication session with the 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 for selecting a video session, a conference session, or a web messaging session to connect the patient to the 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 calls.

[0358] In some embodiments, a patient may initiate a session. Application 1002 is configured to enable the patient to request to contact a clinician (including specifying a preferred communication method). Using the text features of Application 1002, the patient may send a text message including the text "Help" to the assistance module 1112 to start a session. After the patient requests to start a session, the assistance module 1112 is configured to identify available clinicians. In some embodiments, the assistance module 1112 may find the clinician record associated with the patient and send a pin / request message to that device. A response received from one of the devices 152 provides an indication that 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 assistance module 1112 starts 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 the pin message to a group of clinicians, the assistance module 1112 may sequentially send the pin / request message to clinicians according to a predetermined order (e.g., first, the most critical clinician, second, the clinicians waiting in the same office, third, the clinicians waiting in different offices, etc.). FIG. 33 shows a schematic diagram of a user interface 3300 of Application 1002 that provides a video session with a clinician. The video session enables the patient to address their concerns regarding their treatment. The video session also enables the clinician to view the real-time settings of the treatment or assist the patient in setting up the treatment.

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

[0360] The exemplary assistance module 1112 may determine the type of assistance required to identify the correct individual for the connection. In addition to the clinician, the assistance module 1112 may be able to connect to information technology specialists and home therapy machine specialists. Before starting the session, the application 1002 may prompt the patient to identify the type of assistance (e.g., application help, machine help, clinical help, etc.). In other cases, the assistance module 1112 may determine the type of assistance based on the context in which the requirements for the session were received. For example, after reviewing an educational training program for the home therapy machine 90, the assistance module 1112 determines that subsequent requests for assistance relate to operating the home therapy machine 90. In another example, while the application 1002 is displaying a user interface regarding UF trends, the assistance module 1112 determines that subsequent requests for assistance relate to clinical issues.

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

[0362] (III. Conclusion) It should be understood that various changes and modifications of the 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 subject matter and without diminishing its intended advantages. Accordingly, such changes and modifications are intended to be covered by the appended claims.

Claims

1. A system for transmitting information to a patient, the system comprising: the patient's home therapy machine configured to transmit treatment information; a clinician database configured to store medical records and a registration file, the registration file identifying (i) the home therapy machine and the patient's personal device as registered devices, and (ii) whether the personal device has installed an application for viewing the treatment information; a clinician server communicatively coupled to the clinician database, the home therapy machine, and the personal device; comprising; the clinician server is configured to: store the treatment information in the medical records; receive an instruction that at least a portion of the treatment information should be displayed on the personal device; determine from the registration file whether the application is installed on the personal device; if the application is installed, convert at least a portion of the treatment information into an application format for display within the application; transmit the converted at least a portion of the treatment information to the personal device; and if the application is not installed, convert at least a portion of the treatment information into a text message format or a short messaging service ( "SMS") format; transmit the converted at least a portion of the treatment information to the personal device via one or more text messages or SMS messages; and is configured to perform. A system.

2. The system according to claim 1, wherein the application format includes at least one of an extensible markup language ( "XML") format or a hypertext markup language ( "HTML") format.

3. The system according to claim 1, wherein the instruction that at least a portion of the treatment 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.

4. The registration file is the system according to claim 1 included in the medical record.

5. The home therapy machine is configured to store a prescription using two programs, each of the programs providing parameters for operating the home therapy machine to perform a treatment, and the clinician server receives a program message from the personal device indicating a change from the first program to the second program, and transmits program instructions for changing from the first program to the second program to the home therapy machine The system according to claim 1, which is configured to perform.

6. The home therapy machine includes at least one of 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 scale, and a heart rate monitor, according to claim 1. System.

7. The treatment information includes at least one of blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual exchange data, subjective data, or consumable data regarding consumable items, according to claim 1. System.

8. 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, an adsorbent cartridge, and a purified water container, according to claim 7. System.

9. The personal device is a personal mobile communication device, according to claim 1. System.

10. A method for transmitting information to a patient, the method comprising: storing a registration file in a clinician database, the registration file identifying (i) a home therapy machine and the patient's personal device as registered devices, and (ii) whether the personal device has installed an application for viewing treatment information; , and receiving the treatment information from the patient's home therapy machine in the clinician database; storing the treatment information in the patient's medical record via a server in the clinician database; receiving, at the server, an indication that at least a portion of the treatment information should be displayed on the personal device Determining, via the server, whether the application is installed on the personal device from the registration file; If the application is installed, Converting, via the server, at least a part of the treatment information into an application format for display within the application; Transmitting, via the server, at least the converted part of the treatment information to the personal device And doing; If the application is not installed, Converting, via the server, at least a part of the treatment information into a text message format or a short messaging service ("SMS") format; Transmitting, via the server, at least the converted part of the treatment information to the personal device via one or more text messages or SMS messages And doing A method comprising.

11. The method according to claim 10, wherein the application format includes at least one of an extensible markup language ("XML") format or a hypertext markup language ("HTML") format.

12. The method according to claim 10, wherein the instruction that at least a part of the treatment 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.

13. The method according to claim 10, further comprising converting the treatment information into a Health Level 7 ("HL7") format via the server before storing it in the medical record.

14. The home therapy machine is configured to store a prescription using two programs, each of the programs providing parameters for operating the home therapy machine to perform a treatment, and the method includes: Receiving, at the server, a program message indicating a change from a first program to a second program from the personal device; Transmitting, via the server, program instructions for changing from the first program to the second program to the home therapy machine The method according to claim 10, further comprising.

15. The method according to claim 10, wherein the treatment information includes at least one of blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual exchange data, subjective data, or consumable data regarding consumable items.

16. A system for transmitting information to a patient, the system comprising: A clinician database configured to store medical records and registration files, wherein the registration files identify (i) a home therapy machine and the patient's personal device as registered devices, and (ii) whether the personal device has installed an application for viewing treatment information from the home therapy machine; a clinician database; A clinician server communicatively coupled to the clinician database, the home therapy machine, and the personal device And comprising The clinician server is Converting the treatment information received from the home therapy machine into a Health Level 7 ("HL7") format; Storing the converted treatment information in the medical record; Receiving an instruction that at least a portion of the converted treatment 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 a portion of the converted treatment information into an application format for display within the application; Transmitting the at least a portion of the converted treatment information to the personal device And performing If the application is not installed, Converting the at least a portion of the converted treatment information into a text message format or a Short Message Service ("SMS") format; Transmitting the at least a portion of the converted treatment information to the personal device via one or more text messages or SMS messages And performing A system configured to perform.

17. The system according to claim 16, wherein the application format includes at least one of an Extensible Markup Language (XML) format or a Hypertext Markup Language (HTML) format.

18. The system according to claim 16, wherein the instruction that at least a part of the treatment 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.

19. The personal device is a personal mobile communication device, The home therapy machine includes at least one of a renal failure therapy machine, an infusion pump, an oxygen sensor, a respiratory monitor, a glucose meter, a blood pressure monitor, an ECG monitor, a weighing scale, and a heart rate monitor, according to claim 16.

20. The system according to claim 16, wherein the treatment information includes at least one of blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual exchange data, subjective data, or consumable data regarding consumable items.

Images