JP7708838B2 - Medical fluid delivery systems including mobile platforms for patient engagement and treatment compliance - Google Patents

Description

Engaging patients outside of a medical environment for extended periods of time is currently a virtually impossible task. Similar to getting a gym membership or buying a treadmill, many patients are typically overeager. For example, from the get-go, patients are likely to be reluctant to adopt a medical treatment (e.g., a medical fluid delivery treatment) that is self-administered in the patient's home. With regard to the treatment, the patient needs to connect themselves to a medical fluid delivery machine (or a container containing renal failure treatment fluid) to cleanse their blood from toxin buildup. Part of the treatment may include tasks that the patient needs to perform, such as weighing themselves, measuring their blood, and/or recording information related to their treatment. The information recorded by the patient is often reviewed by a clinician to ensure that the treatment is progressing as prescribed. The clinician also reviews the recorded data to determine if an adjustment in the treatment is required.

Over time, many patients become disengaged as the treatment loses its novelty and becomes a mundane obligation. As one might imagine, patients would rather engage in activities that are more exciting, relaxing, or stimulating compared to self-administered medical treatment. As patients continue with their treatment, they sometimes begin to skip performing the additional tasks that accompany the treatment. Omitting additional tasks and becoming disengaged has the potential to create gaps in clinical oversight of ongoing treatment. As patients become more disengaged, they may begin to skip treatments or do without them entirely, endangering their own health in the process.

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

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

Additionally, the exemplary medical fluid data transfer system provides a gateway for the clinician to allow 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 the 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 remain engaged and/or compliant with the treatment.

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

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

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

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

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 herein and without limiting the disclosure in any way, a machine-accessible device has instructions stored thereon that, when executed, are configured to cause a machine to populate a patient medical record of a clinical system by operating a camera to record an image, operating a display interface, and operating a connection interface configured to connect to a clinician database, the clinician database being configured to store patient medical records, and operating a processor to obtain medical information. The processor is operated to obtain medical information by displaying, via the display interface, a user interface with fields in which the medical information is to be populated, 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. If the first option is selected, the processor receives a recorded image from the camera, the recorded image including a medical device or a screen of the medical device, extracts text from the image, and enables selection of at least a portion of the text from the image via the display interface and writes the selected text from the image into a data field of the user interface as medical information. If the second option is selected, the processor enables text entry into the data field as medical information via the display interface. The processor is also operated to obtain the medical information by transmitting the medical information written into the data field to a patient medical record stored in a clinician database after the send instruction is received.

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

According to a third aspect of the present disclosure, which may be used in combination with any other aspect recited herein unless otherwise stated, the data template is configured to define a context for the extracted text relative to the text location within the image.

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

According to a fifth aspect of the present disclosure, which may 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 bar code, a serial number, or a hardware number located on a housing of the medical device or on a screen of the medical device.

According to a sixth aspect of the present disclosure, which may 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 weight scale, and a heart rate monitor.

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

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

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

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

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

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

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

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

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

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

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

According to an eighteenth aspect of the present disclosure, which may 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.

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

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

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

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

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

Providing an improved patient lifestyle is another advantage of the present disclosure.

It is a further advantage of the present disclosure to provide improved clinician or caregiver efficiency.

It is yet another advantage of the present disclosure to provide improved mechanical efficiency.

It is yet a further advantage of the present disclosure to provide improved patient compliance.

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

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

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

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

FIG. 1 is a schematic diagram illustrating one embodiment of a medical fluid data transfer system incorporating a medical fluid delivery machine of the present disclosure such that data may be transferred to and from such machine, in accordance with an embodiment of the present disclosure.

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

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

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

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

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

FIG. 7 is a schematic diagram of one embodiment of a hospital or clinical version of the disclosed medical fluid delivery device and data transfer system and method having a mobile communication device application in a first state.

FIG. 8 is a schematic diagram of one embodiment of a hospital or clinical version of the disclosed medical fluid delivery device and data transfer system and method having a mobile communication device application in a second state.

FIG. 9 is a schematic diagram of one embodiment of a hospital or clinical version of the disclosed medical fluid delivery device and data transfer system and method having a mobile communication device application in a third state.

FIG. 10 illustrates a second embodiment of a medical fluid data transfer system.

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

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

FIG. 13 illustrates an example patient data structure stored on a clinician database of the medical fluid data transfer system of FIG. 10, according to certain example embodiments of the present disclosure.

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

FIG. 16 is a schematic diagram of the personal mobile communications device of FIGS. 10 and 11, according to certain exemplary embodiments of the present disclosure.

FIG. 17 illustrates a schematic diagram of a data template, according to certain example embodiments of the present disclosure.

FIG. 18 shows a diagram illustrating filling in data fields of the user interface of FIG. 14 according to certain exemplary embodiments of the present disclosure.

FIG. 19 is a flow diagram of an exemplary procedure for inputting medical information from an image using the application of the personal mobile communication device of FIGS. 10 and 11 according to certain exemplary embodiments of the present disclosure.

FIG. 20 shows an example of a user interface displayable by an application on the personal mobile communications device of FIGS. 10 and 11 that allows a patient to provide recorded images, according to certain exemplary embodiments of the present disclosure.

FIG. 21 shows a schematic diagram of a patient medical template used by the clinician server of FIGS. 10 and 11 to populate data fields in a patient's medical record, according to certain exemplary embodiments of the present disclosure.

FIG. 22 is a schematic diagram of a data acquisition module of the clinician server of FIG. 11, according to an exemplary embodiment of the present disclosure.

23 and 24 are flow diagrams of an example procedure for populating the medical device template of FIG. 21 using images recorded by (and/or text messages received from) the personal mobile communication devices of FIGS. 10 and 11, in accordance with certain example embodiments of the present disclosure. 23 and 24 are flow diagrams of an example procedure for populating the medical device template of FIG. 21 using images recorded by (and/or text messages received from) the personal mobile communication devices of FIGS. 10 and 11, in accordance with certain example embodiments of the present disclosure.

FIG. 25 shows a schematic diagram of a clinician server hosting a website or file transfer site for receiving medical information via images from the personal mobile communication devices of FIGS. 10 and 11 according to certain exemplary embodiments of the present disclosure.

26-29 show schematic diagrams of personal mobile communication devices displaying medical information provided by the clinician server of FIGS. 10 and 11, according to exemplary embodiments of the present disclosure. 26-29 show schematic diagrams of personal mobile communication devices displaying medical information provided by the clinician server of FIGS. 10 and 11, according to exemplary embodiments of the present disclosure. 26-29 show schematic diagrams of personal mobile communication devices displaying medical information provided by the clinician server of FIGS. 10 and 11, according to exemplary embodiments of the present disclosure. 26-29 show schematic diagrams of personal mobile communication devices displaying medical information provided by the clinician server of FIGS. 10 and 11, according to exemplary embodiments of the present disclosure.

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

FIG. 31 shows a schematic diagram of the personal mobile communication device of FIGS. 10 and 11 providing a program regarding medical treatments to be selected for a patient, according to certain exemplary embodiments of the present disclosure.

FIG. 32 shows a schematic diagram of the personal mobile communication device of FIGS. 10 and 11 providing educational content to a patient, according to certain exemplary embodiments of the present disclosure.

FIG. 33 shows a schematic diagram of the personal mobile communication device of FIGS. 10 and 11 providing a video chat session between a patient and a clinician, according to certain exemplary embodiments of the present disclosure.

A medical fluid delivery system is disclosed herein. An exemplary medical fluid delivery system is configured to improve patient engagement with a medical treatment, such as a medical fluid delivery treatment. The medical fluid delivery system is configured to provide the patient with more transparency regarding and at least some control to direct their treatment, while providing resources to educate or otherwise assist the patient throughout the treatment process. The exemplary medical fluid delivery system is configured to provide patient engagement regardless of the type or feature set of 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.

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

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 in a clinician database. The clinician server provides access to the medical fluid delivery data to a personal mobile communication device, allowing the patient to track treatment progress. In addition, 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.

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

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

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

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

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

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

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

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

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

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

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

Automated peritoneal dialysis ("APD") is similar to CAPD in that the dialysis treatment includes drain, fill, and dwell cycles. However, APD machines typically perform the cycles automatically while the patient sleeps. APD machines relieve the patient from having to manually perform the treatment cycles and from having to transport supplies during the day. APD machines fluidly connect to an implanted catheter, a source or bag of fresh dialysis fluid, and a fluid drain. The APD machine pumps fresh dialysis fluid from the dialysis fluid source, through the catheter, and into the patient's peritoneal cavity. APD machines also allow the dialysis fluid to dwell within the cavity, allowing transfer of waste, toxins, and excess water to occur. The source may include multiple sterile dialysis fluid bags.

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

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

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

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

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

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

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

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

Whenever the machine is in the "patient connected" software state, it is envisioned that the software of the disclosed system and methodology will disable communications between the patient and/or caregiver and the machine. For example, if a clinician attempts to send a command to a machine that is currently treating a patient, the command may be blocked by the middleware software application so that the command is not forwarded to that machine. The middleware software application may then reply to the clinician to inform them that the machine is busy and will not accept communications.

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

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

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

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

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

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

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

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

The home therapy machine 90 in an embodiment writes a log file using, for example, a Linux operating system. The log file documents the relevant home therapy machine 90 data, including peripheral device data. The log file may include any one or more of the following: Extensible Markup Language ("XML"), Comma Separated Values ("CSV"), or text files. The log file is installed in a file server box of the home therapy machine 90 software. It is also envisioned that data not transmitted to the machine 90 may be stored in a peripheral device, for example, the water treatment device 60. Such data may be otherwise obtained via a wired or wireless connection to the peripheral device, or may be downloaded through other data connections or storage media. For example, maintenance personnel may access the additional data via a laptop connected to the water treatment device 60 or the wireless meter 106, for example, via an Ethernet connection. Alternatively, the additional data may be read remotely from the peripheral device, with the home therapy machine 90 serving as a data transfer communication conduit between the peripheral device and an authorized client of the medical fluid data transfer system.

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

The connectivity agent 114 allows the home therapy machine 90 to connect to the connectivity server 118 and transfer data to and from the connectivity server 118. The connectivity services operating through the agent 114 and server 118 ensure that the connection with the machine 90 is secure, ensure that data passes correctly through the firewall of the machine 90, check if there are any data or system crashes, and ensure that the connectivity server 118 is communicating with the correct home therapy machine 90.

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

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

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

The medical fluid delivery machine 90 of FIG. 2 includes a blood circuit 20. The blood circuit 20 draws blood from and returns blood to the patient 12. Blood is drawn from the patient 12 via an arterial line 14 and returned to the patient via a venous line 16. The arterial line 14 includes an arterial line connector 14a, which connects to an arterial needle 14b, which is in blood draw communication with the patient 12. The venous line 16 includes a venous line connector 16a, which connects to a venous needle 16b, which is in blood return communication with the patient. The arterial and venous lines 14 and 16 include line clamps 18a and 18v, which may be spring-loaded fail-safe mechanical pinch clamps. The line clamps 18a and 18v, in one embodiment, are automatically closed in an emergency situation.

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

A blood pump 30 is located in the arterial line 14 in the illustrated embodiment. 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 an embodiment, each of the blood pump pods 30a and 30b is a blood container, which includes, for example, a spherical rigid outer shell with a flexible diaphragm located within the shell to form a diaphragm pump. One side of each diaphragm receives blood while the other side of each diaphragm is operated by positive and negative air pressure. The blood pump 30 is alternatively a peristaltic pump that operates with the arterial line 14 or multiple peristaltic pumps that operate with the arterial line 14 and the venous line 16.

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

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

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

The dialysis fluid circuit 70 is again greatly simplified in FIG. 2 for ease of illustration. In reality, the dialysis fluid circuit 70 may include all of the relevant structures and functionality described in the publications incorporated by reference above. Certain features of the dialysis fluid circuit 70 are illustrated in FIG. 2. In the illustrated embodiment, the dialysis fluid circuit 70 includes a hemofilter-directed dialysis fluid pump 64. The pump 64 is configured the same as the blood pump 30 in one embodiment. Like the pump 30, the pump 64 includes a pair of pump pods 66, each having an inlet valve 68i and an outlet valve 68o, which again may be configured spherically. The two pump pods are operated alternately, as for the blood pump 30, whereby one pump pod fills with HD dialysis fluid while the other pump pod expels HD dialysis fluid.

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

A fifth pod pump (not shown) provided in the exhaust line 82 is used to remove a known amount of ultrafiltration ("UF") as HD therapy is provided. The system 10 tracks the UF pump to control and keep track of 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 therapy.

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

In one embodiment, purified water from the water purification unit 60 is pumped along a mixing line 62 through a bicarbonate cartridge 72. Acid from a container 74 is pumped along the mixing line 62 into the bicarbonate water flowing from the bicarbonate cartridge 72 to form an electrolytically and physiologically compatible dialysis fluid solution. 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.

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

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

In the illustrated embodiment, the medical fluid delivery machine 90 is a continuous, continuous pass-through system in which the system pumps dialysis fluid once through the hemofilter and then pumps the used dialysis fluid to drain. Both the blood circuit 20 and the dialysis fluid circuit 70 can be hot water 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 hot water disinfected and reused daily for about one month, while the dialysis fluid circuit 70 is hot water disinfected and reused for about six months.

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

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

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

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

B. Exemplary Medical Fluid Delivery System Connectivity Embodiments
Referring now to Figure 4, a system 110a of the present disclosure is illustrated. The system 110a in the illustrated embodiment operates in conjunction 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 Figure 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 may be part of the cloud environment or may be located on one or more dedicated servers.

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

The 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, the machines 90a and 90b connect to the Internet 52, for example, via the modem 102 discussed above. The system hub 120 in one embodiment stores middleware software that can be accessed by the mobile communication devices 200a and 200b (collectively referred to herein as device 200, or generally and individually as device 200). The mobile communication devices 200a and 200b can be, for example, smartphones running on Android, iOS, Windows Phone, BlackBerry, Sailfish OS, Tizen, or Ubuntu Touch operating systems. The mobile communication devices 200a and 200b may belong to the patients 12a and 12b, respectively, and/or to the clinicians 112a and 112b, respectively. The mobile communication devices 200a and 200b as illustrated in FIG. 4 are also connected to the Internet 52.

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

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

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 will convert the code from the machine 90b into a message that is embedded on the native task tracking feature of the device 200, such as its calendar application. Most smartphone devices 200 are provided with a calendar that separates each day into time segments, such as hours, for example. Here, the message converted by the middleware software of the system hub 120 can be programmed to access the calendar of the authorized communication device 200b and populate the appropriate time segment for the appropriate day with the appropriate information. In the above example, for the appropriate day, the native calendar software application would have its 10:00:00 AM time slot filled with a message such as "Please begin treatment preparation in 2 hours." Audio and/or haptic feedback signals can be provided to notify the patient 12 or clinician 112 of the calendar entry.

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

Now referring to FIG. 5, a system 110b of the present disclosure is illustrated. The system 110b in the illustrated embodiment operates in conjunction 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 may alternatively 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, multiple medical fluid delivery machines 90 may be connected to the system 110b as well. The medical fluid delivery machines 90 may be present in the home of the patient 12 (illustrated as being outside the home) or in the 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, again using, for example, a modem 102 in the illustrated embodiment.

The system hub 120 in one embodiment stores middleware software that can be accessed by the mobile communication device 200 (shown as a single device for simplicity, but multiple devices 200 can be connected to the system 110b as well). The mobile communication device 200 of FIG. 5 includes all of the structure, functionality, and alternatives disclosed with respect to the devices 200a and 200b illustrated in FIG. 4, including being connected to the Internet 52. In FIG. 5, the mobile communication devices 200 can, but need not, download software applications ("apps") from middleware software stored on the system hub 120 via their connection to the Internet 52. The apps can be operated exactly as described above in connection with FIG. 4 (including middleware software that converts coded messages 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 be capable of converting the code from the machine 90 into a message that is embedded on the native task tracking feature of the mobile communication device 200, such as its calendar application, in any of the ways described in FIG. 4.

Further alternatively or in addition, system 110b includes cellular network 210 interfacing between middleware software stored in system hub 120 and mobile communications device 200, for example. Cellular network 210 may include a network of cellular telephone towers operating using radio waves and/or may employ satellites. Communication protocols suitable for use with cellular network 210 of system 110b may be (i) a long-range protocol such as the "Worldwide Interoperability for Microwave Access" ("WiMAX") protocol and (ii) the "Global System for Mobile Communications" ("GSM") protocol, which is a wide-ranging long-range wireless protocol enabling data communications to many of the cellular telephones worldwide. Network 210 may alternatively or additionally employ a medium-range protocol such as a wireless local area network ("WLAN"), which may be a protocol that is part of the Institute of Electrical and Electronics Engineers ("IEEE") 802.11 standard, such as (i) IEEE 802.11a, (ii) IEEE 802.11b, (iii) WEE 802.11g, or (iv) 802.11n. Other suitable cellular technologies may include CDMA, AMPS (analog), General Packet Radio Service ("GPRS"), cdmaOne, CDMA2000, Evolution Data Optimized ("EV-DO"), Enhanced Data Rates for GSM Evolution ("EDGE"), Universal Mobile Telecommunications System ("UMTS"), Digital Cordless Telephone Standard ("DECT"), Digital AMPS ("IS-136/TDMA"), and Integrated Digital Enhanced Network ("iDEN").

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

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

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

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

In another example, the medical fluid delivery machine 90 may be preprogrammed to begin 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 clinician 112 must therefore be at the machine 90 by noon to begin pre-treatment. In one embodiment, the patient 12 or clinician 112 sets a preference on the machine 90 as to how far in advance of the 3 hour preparation time the patient 12 or clinician 112 should be notified or alerted (e.g., 2 hours). Here, the machine 90 generates a code at 10:00 AM and sends the code to middleware software stored on the system hub 120. The middleware software then converts the code, e.g., using a lookup table, into a message such as "Please begin preparation for treatment in 2 hours" and causes, e.g., the cellular output routine discussed above to send a text message to the mobile communication device 200 of the patient 12 or clinician 112 and display the message along with an audio alert, e.g., a "beep" sound and/or a tactile alert, e.g., a vibration, that prompts the patient 12 or clinician 112 to view the notification.

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

6, a system 110c of the present disclosure is illustrated. The system 110c in the illustrated embodiment operates in conjunction 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 may alternatively 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, multiple medical fluid delivery machines 90 may be connected to the system 110b as well. The medical fluid delivery machines 90 may be present in the home of the patient 12 (illustrated as being outside the home) or in the clinics 126a-126n associated with 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, again in the illustrated embodiment using, for example, a modem 102. In FIG. 6, the connection server 118 and the securely managed connection 116 are used for bidirectional communication.

The system hub 120 in one embodiment stores middleware software that can be accessed by the mobile communication device 200 (shown as a single device for simplicity, but multiple devices 200 can be connected to the system 110b as well). The mobile communication device 200 of FIG. 6 includes all of the structure, functionality, and alternatives disclosed with respect to the devices 200a and 200b illustrated in FIG. 4, including being connected to the Internet 52. In FIG. 6, the mobile communication devices 200 can, but need not, download software applications ("apps") from middleware software stored on the system hub 120 via their connection to the Internet 52. The apps can be operated exactly as described above in connection with FIG. 4 (including middleware software that converts coded messages 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 be capable of converting the code from the machine 90 into a message that is embedded on the native task tracking feature of the mobile communication device 200, such as its calendar application, in any of the ways described in FIG. 4. The calendar application may alternatively be updated via the cellular network 210 (alternatively illustrated in FIG. 6 via a dashed leader line) discussed above in connection with FIG. 5.

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

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

Determining when to disconnect (no communication) the connectivity agent 114 may depend on the content or number of machine conditions that the systems 110a-110c desire to communicate to the mobile communication device 200. For example, assume it is only desired to inform the patient 12 or clinician 112 two hours prior to treatment preparation that the patient 12 or clinician 112 needs to return to the machine 90 to begin treatment preparation. Here, the connectivity agent 114 may be turned off as soon as the patient 12 or clinician 112 begins the first treatment preparation step, e.g., running a self-test routine.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The nurse, clinician, or doctor 112 may toggle the alert on/off icon 238 to enable or not enable status changes regarding the machines 90a-90n to be visually, audibly, and/or tactilely alerted. When the alert on/off icon 238 is toggled "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," whenever the machine status changes. In some embodiments, the codes for (i)-(v) are sent through the secure managed connection 116, the connection server 118, and the system hub 120 or local system hub 220 via the machine 90a-90n, translated by middleware software, and forwarded to the app 230, which updates the appropriate icon 190. In various embodiments, "(vi) Treatment Complete" is (a) sent via the machine 90a-90n with the connectivity agent 114 activated, or (b) inferred when the countdown timer of the appropriate icon 190a-190n expires and if the connectivity agent 114 is still off.

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

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

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

In the illustrated embodiment, when the disinfect button 240b is selected, any machines 90a-90n capable of performing disinfection at that time have their corresponding icons 190a-190n highlighted. The nurse, clinician, or doctor 112 selects any icon 190 for the machine 90 on which the nurse, clinician, or doctor 112 wishes to perform disinfection. That selected icon 190 may again turn into a "Confirm" button that the nurse, clinician, or doctor 112 must press again to have the selected machine 90 perform its disinfection. The app 230 on the mobile communication device 200 then transmits the corresponding disinfection code to the middleware software at the system hub 120 or local system hub 220, which converts the disinfection code, if necessary, into a start disinfection command, which is transmitted to the connectivity agent 114 of the selected machine 90 via the securely managed connection 116 via the connectivity server 118, which forwards the command to the machine's ACPU 50, which in turn begins disinfection.

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

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

In one embodiment, when a mobile communication device 200 transmits data to a system hub 120 or a local system hub 220 for delivery to a machine 90, the data is provided with a mobile communication device 200 identifier that identifies the mobile communication device 200 that transmitted the data. The system hub 120 or the local system hub 220 may or may not transform 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 transformed data, and transmits, for example, the transformed data to each associated communication device 200. The connection server 118 may remove the mobile communication device 200 identifier from the data once it is delivered to the machine 90, since it is no longer needed.

The app 230 as described above allows a nurse, clinician, or doctor 112 to set up, monitor, and possibly control treatment on the medical fluid delivery machine 90. It is envisioned to provide similar functionality via the app to the patient 12 or a caregiver for the patient 12 at the patient's home (dashed box in FIG. 1). The connectivity may be identical to that shown in FIGS. 7-9. However, the setting is not a clinic 126a-126n, but instead is a home or other non-clinical location such as a business or vacation location. In addition, typically there is only a single machine 90, rather than multiple machines 90a-90n. However, it is possible that a single patient 12 may be treated via multiple machines 90, each of which may be supported by an app as described herein. If the patient 12 is at home but away from the machine 90, the app may provide useful information such as the amount of time remaining to initiate or complete start-up procedure tasks, disinfection procedures, or self-test routines. When the patient is being treated by the machine 90, the patient can review information on its user interface 122, which itself can be a tablet as illustrated in FIG. 1. However, there can also be a caregiver, such as a spouse, friend, or home nurse, assisting the patient 12 at home during treatment. The caregiver benefits from the home app by receiving status updates, time remaining for start-up procedure, time remaining for disinfection, time remaining for priming, time remaining for treatment, 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, so that only authorized persons can view the patient treatment data or information.

II. PATIENT ENGAGEMENT EMBODIMENTS
The exemplary medical fluid delivery data transfer system 10 disclosed above in connection with Figures 1-9 is configured to improve patient engagement with medical fluid delivery therapies, such as dialysis therapy, renal failure therapy, and/or peritoneal therapy. Figure 10 illustrates an exemplary medical fluid data transfer system 1000, similar to the medical fluid data transfer system 10 discussed in connection with Figures 1-9, in accordance with certain exemplary embodiments of the present disclosure. The exemplary medical fluid data transfer system 1000 (e.g., a mobile platform) is configured to improve patient engagement and/or compliance with therapy by providing features for controlling and reporting therapy-related information to patients that enhance therapy transparency, and/or provide access to educational materials and/or real-time assistance from clinicians.

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

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

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

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

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

The exemplary blood pressure monitor 104 includes any device configured to measure a patient's blood pressure and/or pulse. For example, the blood pressure monitor 104 may measure the patient's blood pressure before, during, and/or after a renal failure therapy treatment. The blood pressure monitor 104 may display a digital value 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 blood pressure values before, during, and/or after treatment in a separate window such that when medical information is recorded, patient input is required to view all values. 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 smart watch or a fitness tracking device.

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 therapy consumable items 1006. FIG. 10 shows examples of consumable items 1006 including, for example, a renal failure therapy medical device filter, a disposable cassette, a blood line set, a drug delivery line set, and a container (e.g., a dialysate concentrate container, a blood anticoagulant container, a medicine container, and/or a purified water container). The consumable items 1006 may also include sorbent cartridges or any other disposable or substance source for medical treatment. The consumable items may include an identifier 1008 configured to provide medical information in the form of consumable information or consumable data. For example, the identifier 1008 may include information identifying the type of consumable item, a serial number, and/or characteristics of the consumable item. In some cases, the consumable items 1006 may also include an indicia that includes medical information, such as chemical composition characteristics. The patient or clinician uses the personal mobile communication device 200a to record an image of the identifier 1008, an image of the label on the consumable item 1006, and/or an image of the consumable item 1006 itself to document the substances used during treatment.

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

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

In some embodiments, the personal mobile communication device 200a is configured to record, display, and/or populate a patient medical record with medical information or data. As disclosed herein, medical information or data includes medical device data and patient data, which may refer to data or information created by, generated by, or otherwise related to a medical device, a patient, and/or consumable items used by the medical device. For example, medical information includes prescription or programming information used by a medical device to administer a treatment. Medical information includes sensed data such as fluid pressure, flow rate, conductivity, concentration, temperature, and patient data. As provided herein, patient data (e.g., vital signs 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 the patient's mood (e.g., bored, fatigued, satisfied, excited, etc.). Medical information may be displayable on a screen of the medical device, provided by a physical dial or display of the medical device, or printed on an attached sign or on the medical device. Thus, medical device data or medical information includes medical device settings, medical device readings, and/or patient readings.

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

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

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, for example, encode the assigned device number, serial number, hardware number, model number, and/or device type of each medical device 90, 104, and 106. For example, the identifier 1012b of the home therapy machine 90 may store the assigned device number. The personal mobile communication device 200a reads the identifier 1012b from the screen of the machine 90, for example, to determine the medical device type for subsequent analysis and identification of medical information in recorded images. In some embodiments, the identifier 1012 may more generally indicate the model or type of the medical device. For example, the identifier 1012c may indicate that the device 106 is a weighing scale and/or indicate the model number of the weighing scale.

The identifier 1012 may include machine-readable markings, such as, for example, a bar code or a quick response ("QR") code. The identifier 1012 may also include human-readable text, such as a serial number, an asset number, or a hardware number. In some embodiments, the identifier 1012 may be printed on an item physically attached to the housing of the respective medical device 90, 104, and 106, such as the identifier 1012b shown for the home therapy machine 90. Additionally or alternatively, the identifier 1012 may be displayed on the screen of some of all of the medical devices 90, 104, and 106. For example, the 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 in a radio frequency ("RF") microchip, such as an RFID chip or an NFC chip.

The exemplary medical devices 90, 104, and 106 may also include one or more control interfaces for providing control instructions. For example, the home therapy machine 90 includes a control interface 1014. The control interface may include buttons, a control panel, or a touch screen. The control interface may be configured to allow a user to navigate to certain windows or user interfaces on the screen of the respective medical device 90, 104, and 106. The control interface may also provide instructions for operating or controlling the respective medical device 90, 104, and 106.

10, the exemplary fluid data transfer system 1000 includes a web portal 150, a system hub 120, and a clinician server 200b (similar to the respective devices discussed in connection with FIGS. 1-9) for communicating with the personal mobile communication device 200a. The web portal 150, the system hub 120, and/or the clinician server 200b transmit medical information from the patient's medical record (stored in the clinician database 1010) to the personal mobile communication device 200a. In addition, the web portal 150, the system hub 120, and/or the clinician server 200b may provide the personal mobile communication device 200a with access to educational materials or real-time help sessions with a clinician. The exemplary web portal 150, the system hub 120, and/or the clinician server 200b are also configured to enable the personal mobile communication device 200a to provide medical information for populating the patient's medical record.

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

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

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

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

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

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

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

The application 1020 may also include a data acquisition module 1104 configured to receive treatment and/or medical information from the registered home therapy machine 90 and/or personal mobile communication device 200a. In addition, the 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. The application 1020 may further include an education module 1108 configured to provide access to educational materials or help documents for the patient regarding their treatment and/or the operation of the home therapy machine 90. Furthermore, the application 1020 may include a treatment control module 1110 that allows the patient (or clinician) to change (or modify) the treatment program implemented by the home therapy machine 90. The application 1020 may additionally include an auxiliary module 1112 that creates a real-time communication session between the personal mobile communication device 200a and the clinician device 152.

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

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

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

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

In some embodiments, there are different registration scenarios. For example, a patient may register the home therapy machine 90 while registering the personal mobile communication device 200a by downloading the application 1002. In this scenario, the registration module 1102 records that the patient has installed the application 1002 on the personal mobile communication device 200a and registered the home therapy machine 90 (either separately or through the application 1002). Based on this registration, the data acquisition module 1104 determines that the application 1002 installed on the registered personal mobile communication device 200a should guide or otherwise prompt the patient to obtain medical information. In addition, the data acquisition module 1104 determines that the treatment information should be received from the home therapy machine 90, rather than via the personal mobile communication device 200a. In response, the data acquisition module 1104 may send a message to the application 1002 to disable the user interface to obtain treatment information from the home therapy machine 90 (but still enable the user interface for manual exchange if manual exchange is prescribed for the patient). If the home therapy machine 90 is not registered, the data acquisition module 1104 causes the application 1002 to display a user interface for obtaining therapy information from the home therapy machine 90 in the application 1002. Through registration, the data access module 1106 determines that information should be displayed through the application 1002 and accordingly uses APIs and/or other data reading components compatible with or configured for the application 1002.

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

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

12 shows a diagram illustrating communication between the home therapy machine 90 of FIGS. 10 and 11, the personal mobile communication device 200a, and the clinician server 200b, according to certain exemplary embodiments of the present disclosure. Initially, the home therapy machine 90 is registered with the clinician server 200b via the registration module 1102 of FIG. 11. Otherwise, the clinician server 200b will not have information regarding the patient record data from the home therapy machine 90 to be stored. In some embodiments, the home therapy machine 90 is preprogrammed 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.

During setup, the patient (or clinician) enters a patient activation code ("PAC") into the home therapy machine 90. The PAC is originally generated and stored in the clinician server 200b and provided to the patient when the patient receives the home therapy machine 90. The PAC may include a patient identifier or other code that is 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 a hardware identifier of the home therapy machine 90 and/or an IP address assigned to the home therapy machine 90. The home therapy machine 90 transmits the message 1202 to a preprogrammed address, in this case, the connectivity server 118. The exemplary connectivity server 118 relays the message 1202 to the system hub 120, which routes the message to the clinician server 200b. The registration module 1102 in the clinician server 200b uses the PAC to register the home therapy machine 90 with the patient. Registration may include, for example, associating an identifier of the home therapy machine 90 with the patient's patient medical record. Registration may also include the clinician server 200b storing an IP address of the home therapy machine 90 to enable messages to be transmitted to the home therapy machine 90. After registration, the data acquisition module 1104 in the clinician server 200b stores the treatment information received from the home therapy machine 90 in one or more medical records associated with the patient.

The exemplary personal mobile communication device 200a is also configured to be registered with the clinician server 200b via the registration module 1102. To register, the personal mobile communication device 200a may download or otherwise receive the application 1002 via one or more messages 1204 from the clinician server 200b (or a third-party application store). In some embodiments, during registration of the home therapy machine 90, the patient (or clinician) may provide a telephone number for the personal mobile communication device 200a. The registration module 1102 uses the telephone number and transmits the message 1204 as a text message. The message may include a hyperlink to a location (e.g., a database 1010 or a third-party website) that provides the application 1002 for download to the personal mobile communication device 200a. In other cases, the message 1204 may include an attachment that, when executed, installs the application 1002 on the personal mobile communication device 200a. Instead of providing a telephone number, the patient may instead provide an email address during registration of the home therapy machine 90. Thus, message 1204 includes an email message with a file or hyperlink for installing application 1002 on personal mobile communication device 200a.

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

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

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

As mentioned above, in some embodiments, the personal mobile communication device 200a may not include an application. In these embodiments, the personal mobile communication device 200a may communicate with the clinician server 200b via text message or through a web browser. Thus, the registration module 1102 of the clinician server 200b may transmit a text message to the personal mobile communication device 200a with a hyperlink to a database or web page for completing the registration. 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 allows the registration module 1102 to associate the personal mobile communication device 200a (e.g., phone number, hardware address, or IP address) with the appropriate patient medical record and/or registration file.

B. Data Acquisition Module Embodiments
FIG. 12 also illustrates data communications between the home therapy machine 90, the personal mobile communications device 200a, and the clinician server 200b. During operation, the home therapy machine 90 generates treatment and status information (e.g., medical information). As discussed above in connection with FIGS. 1-9, treatment information includes the volume of fluid infused, the amount of ultrafiltration ("UF") removed from the patient, and/or treatment time. Status information includes alarms, alerts, or diagnostic information. Before or after treatment, the home therapy machine 90 generates one or more messages 1208 with the medical information, which are transmitted to the connectivity server 118. The connectivity server 118, in turn, routes the messages 1208 to the system hub 120, which routes the messages 1208 to the data acquisition module 1104 of the clinician server 200b. Upon receipt, the data acquisition module 1104 stores the medical information in a designated section of the patient's medical record (e.g., the patient medical record 1302 of FIG. 13). The message 1208 may include an identifier or address of the home therapy machine 90 , which is used by the data acquisition module 1104 to locate the appropriate medical record in the database 1010 .

The exemplary home therapy machine 90 may be configured to code, label, or otherwise identify the medical information being transmitted using metadata or other data identification techniques. The coding or labeling allows the data acquisition module 1104 (or an interface in the server 200b) to determine the context of the medical information to write the medical information into the appropriate field of the patient record. Additionally or alternatively, the coding or labeling may be stored in the record, which is later used to search and display the medical information.

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

FIG. 13 illustrates an example patient data structure 1300 stored on the clinician database 1010 of FIG. 10 in accordance with an example 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.

As shown in FIG. 13, each of the medical records 1302 and 1304 includes data fields identifying the patient, the personal mobile communication device 200a, and the home therapy machine 90. For example, the records 1302 and 1304 include data fields for a patient identifier, a type of personal mobile communication device 200a, a type of home therapy machine 90, and a home therapy machine identifier (received via registration). The patient identifier may correspond to a PAC assigned to the patient. The records 1302 and 1304 may include additional fields for the patient's name, address, gender, date of birth, etc. The records 1302 and 1304 may further include fields for the network 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 and medical information should be presented and/or transmitted to the personal mobile communication device 200a.

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

The treatments and/or medical devices may be organized by treatment, date/time generated, and/or date/time received. In some embodiments, the medical records 1302 and 1304 may store communications from the patient. The communications may include photos or videos recorded by the personal mobile communication device 200a related to the treatment, or questions about the treatment. The communications may also include text messages, emails, etc., related to treatment aids sent from the personal mobile communication device 200a. Additionally, the communications may include information related to requests from the personal mobile communication device 200a and/or the clinician device 152 to change or modify the treatment. Generally, the medical records 1302 and 1304 are configured to store information for improving the patient's engagement in the treatment, in addition to documenting information related to the results of the treatment and the patient's engagement with the clinician server 200b regarding the treatment.

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

1. Manual Entry of Medical Information into the Application Embodiments
To receive the structured information, the exemplary application 1002 of the personal mobile communication device 200a is configured in some embodiments to display a prompt indicating medical information required for entry by the patient into the patient medical record. The exemplary application 1002 may include a routine or algorithm that defines the fields to be displayed to prompt for medical information from the patient. In some embodiments, the fields or screens on which the fields are displayed are arranged and/or ordered in relation to the medical fluid delivery treatment. The display of the fields informs the patient as to the medical information required for the patient record.

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

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

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

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

In the illustrated embodiment, the user interface 1400 includes a systolic blood pressure data field 1402, a diastolic blood pressure data field 1404, and a pulse data field 1406. The patient may select the respective data field 1402, 1404, or 1406 and cause the application 1002 to display a text entry feature for entering a value. The user interface 1400 includes a field 1408 that allows the patient to specify whether the blood pressure measurement was performed in a standing or sitting position. Additionally, the user interface 1400 includes a data field 1410 that allows the user to specify the date/time the blood pressure measurement was performed.

In some examples, the patient may select any one of the 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 instructing the patient how to perform a blood pressure measurement and identify the systolic blood pressure measurement. The tutorial may include text, text/photos, audio recording, animation, and/or video. The tutorial may be stored locally as part of the application 1002 or stored on the clinician server 200b for remote access or streaming.

The user interface 1500 of FIG. 15 is configured to be displayed by the application 1002 when the patient is scheduled to perform a manual exchange therapy and/or if the home therapy machine 90 is not registered with the clinician server 200b. A manual renal failure exchange therapy requires the patient to connect a container of dialysis fluid to their peritoneal cavity for a dwell duration before allowing the spent dialysis fluid to be drained, all without the assistance of the machine. For manual therapy, the patient is required to enter their manual exchange medical information to allow their records to reflect accurate therapy information.

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

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

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

In some embodiments, the application 1002 may identify at least some of the data fields of one or more user interfaces as required for input, while other data fields are optional for input. The application 1002 may outline or otherwise graphically indicate the required data fields (e.g., displaying a red frame around the systolic blood pressure data field 1402). The application 1002 may cause an alert message to be displayed by the personal mobile communications device 200a if the required data fields are not completed or are not completed by a certain time. In some embodiments, the application 1002 may prevent the patient from navigating to another user interface until all required fields are populated with data for the currently viewed user interface.

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

2. Wireless Input of Medical Information into Application Embodiments
In some embodiments, the patient may choose to input medical information wirelessly on his/her personal mobile communication device 200a. The medical information may be received at the personal mobile communication device 200a via, for example, a Bluetooth® connection, a Zigbee® connection, a Z-Wave® connection, a wireless USB connection, a wireless RF connection, an NFC connection, an infrared connection, or any other suitable wireless communication technology. In some cases, the patient may need to wirelessly pair the personal mobile communication device 200a with a medical device such as a blood pressure monitor 104 and/or a weighing scale 106. In other embodiments, the patient activates a connectivity application (e.g., an NFC application) that wirelessly reads the medical information from the medical device.

In one example, a patient may pair their personal mobile communication device 200a with a blood pressure monitor 104. To enter blood pressure medical information into the user interface 1400 of FIG. 14, the user selects, for example, the systolic blood pressure data field 1402. Selection of 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 systolic blood pressure, which causes the systolic blood pressure value to be populated into the systolic blood pressure data field 1402. In some embodiments, the application 1002 is configured to read the medical information from the blood pressure monitor 104 after the device is selected by the patient. The application 1002 may use the data indicators or metadata to determine which fields 1402-1410 should be populated with medical information from the blood pressure monitor 104.

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

3. Image Input of Medical Information into Application
An exemplary application 1002 on the personal mobile communications device 200a is configured to allow a patient to input medical and/or treatment information by recording an image of a medical device or a screen of a medical device. The personal mobile communications device 200a uses a camera 1004 to record one or more images. The application 1002 uses optical character recognition ("OCR") to extract text from the recorded images. The extracted text is populated into one or more data fields of a user interface of the application 1002. The use of images may reduce data entry errors from the patient or clinician.

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

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

The data template defines or prescribes data fields for certain medical information contained within the image. Typically, the image includes extracted text comprising the medical information. In some cases, not all of the extracted medical information is required or needed. Instead, only certain medical information within the recorded image is required for entry into a data field in a user interface or patient medical record. Relevant medical information or relevant medical information refers to medical device data or medical information identified or selected for entry into a data field in a user interface of application 1002, or more generally, for entry into a patient medical record.

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

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

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

In other embodiments, the data processor 1602 may guide the patient through one or more steps to obtain an image. The data processor 1602 may execute a workflow or routine based on the data fields selected by the patient. For example, the data processor 1602 executes a blood pressure workflow to obtain an image from a blood pressure monitor based on the patient selecting the systolic blood pressure data field 1402.

In one example, the data processor 1602 of FIG. 16 is configured to display a camera message identifying the 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 defining the user interface window of the medical device for imaging. Additionally, the data processor 1602 may display a reminder message if an image is not recorded within a predetermined period of time (e.g., 5 minutes). The message may include text providing instructions and/or text identifying the intended target for imaging. The message may also include instructions on how to navigate to a user interface window of the medical device using a control interface of the medical device. The message may further include graphical elements such as an exemplary depiction of the medical device, consumable item, identifier 1012, and/or user interface window in which an image is to be recorded.

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

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 instructions via the camera user interface 1606 (e.g., a touch screen or button on the personal mobile communication device 200a) to record an image. The patient activates the camera user interface 1606, for example, when the camera is focused on the medical device user interface window or identifier 1012. The data processor 1602 receives the instructions and instructs the camera 1004 to record an image. The recorded image is transmitted from the camera 1004 to the image processor 1604. In addition, a copy of the image is displayed by the data processor 1602 on the display interface 1022 of the personal mobile communication device 200a.

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

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

To identify text, image processor 1604 may use, for example, OCR. Additionally, image processor 1604 may determine the location or position of the text relative to the center or origin of the image. In some cases, 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. Image processor 1604 may also use the clock of personal mobile communications device 200a to attach a date/time (corresponding to the time when the image was recorded) to the metadata associated with the image.

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 images. In this example, the image processor 104 may use image matching routines to determine a match. Such a comparison may be made on behalf of the medical device having the identifier 1012. The image processor 1604 may use similar routines and/or algorithms to identify the consumable item 1006.

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

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

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

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

The example data template 1700 of FIG. 17 includes device data (or text) fields 1702, 1704, 1706, and 1708 that 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, whereby image analysis is performed to align the fields 1702-1708 with extracted text in the image. In other examples, the data template 1700 includes a file (or other data structure) that has coordinates or locations for each of the device data fields 1702-1708 relative to an origin. The image processor 1604 identifies the origin in the image with the extracted text and identifies the text for each of the data fields 1702-1708 based on a substantial match to a location in the data template 1700. In some examples, the image processor 1604 may scale the image to match the size or coordinate space of the data template 1700.

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

Matches between sign text, including sign text for unrelated device data fields, may be used to verify that the image is from the correct window or screen of the medical device. For example, the image processor 1604 may match the sign text "ultrafiltration window" to the corresponding extracted text in the relatively same location of the recorded image. The match confirms that the image was recorded from the ultrafiltration window of the renal failure therapy medical device. However, the extracted text is not relevant medical information for the patient's medical record. If the sign text does not match the extracted text, the image processor 1604 may display a message prompting the patient to record an image of the ultrafiltration window of the renal failure therapy medical device.

The indicator text associated with the device data fields 1706 and 1708 may be used to verify that the recorded image is current or has been recorded within a predetermined period of time. For example, some windows on medical devices display the current date and time. This information may 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 date/time rules or limits associated with the device data fields 1706-1708 to determine if the recorded image is current. For example, the image processor 1604 may determine that another image is required to be recorded if the date does not match or if the time is not within a predetermined threshold (e.g., 5 minutes, 15 minutes, 60 minutes, 3 hours, etc.) of the current time on the personal mobile communications device 200a.

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 a selected data field of a user interface (e.g., user interface 1400 or 1500). In comparison, the device data fields 1702, 1706, and 1708 may include flags or metadata indicating that the corresponding extracted data is not related. In the example illustrated in FIG. 17, the image processor 1604 uses the indicator 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 that corresponds to the numerical value of the ultrafiltration volume. The image processor 1604 copies the extracted medical information associated with field 1704b from the image to populate, for example, the systolic blood pressure data field 1402 of FIG. 14.

As discussed above in connection with FIG. 17, the data processor 1602 of FIG. 16 may use the known location of the text and text markers in the image to determine the extracted text that corresponds to the relevant medical information. In some embodiments, the data processor 1602 selects a data template based on an indication of the model or type of medical device and/or consumable item. The indication may be determined from a previous image of the identifier 1012, received from the patient via the camera user interface 1606, and/or specified through the selection of a data field in a user interface for the application 1002 into which the medical information should be entered. In other examples, the data processor 1602 compares the data templates in the database 1608 to the image with the extracted text to find a match. In these other examples, the data processor 1602 uses the location of the text markers and the text between the image and the data template to determine the match.

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

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

After the image 1800 is recorded, the application 1002 performs an OCR operation to extract text. The application 1002 then determines a data template 1801 that corresponds to the extracted text. In some embodiments, the application 1002 matches the location of the text and/or sign in the image to the text and/or sign location in the data template to find a matching data template. In another example, the patient may specify an indication of the blood pressure monitor 104, which allows the application 1002 to find the corresponding data template 1801. In yet another example, the application 1002 may first prompt the patient to record an image of the 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 involves the application 1002 identifying groups or fields of similar text. In some cases, the application 1002 may identify groups or fields of similar text based on spacing between characters and/or words.

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

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

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

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

Prior to block 1906, the patient uses the application 1002 to select data fields and select that medical information should be provided via photo entry. In block 1906, the personal mobile communication device 200a records an image 1907 of the medical device, consumables, 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 text in 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, the personal mobile communication device 200a decodes the barcode and/or the QR code. The imaged or coded 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 data fields for the identified text (block 1910). The data fields 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 certain text and/or define certain textual indicators that are used to operatively place data fields over identified text in the recorded image. In some cases, the data fields and/or data templates may be selected by the patient and/or determined from the medical device identifier 1012. Alternatively, instead of using a template, the procedure 1900 may instead provide an indication that a recently recorded image has relevant medical information for extraction, selection, and/or transfer.

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

If no additional images are required, as determined at decision block 1912, the patient begins a process to populate the data fields of the user interface with the relevant medical information. The process in the illustrated embodiment includes allowing the patient to select an image for which the relevant medical information is to be transferred. Selection of the image causes the personal mobile communications device 200a to display the image on the display interface 1022 (block 1914). It should be appreciated that the selected image includes the identified text and, optionally, the data field. The patient may also specify the data field (or location within the data field) of the user interface into which the data should be populated.

The personal mobile communication device 200a receives a selection of relevant medical information and/or data fields with relevant medical information for populating a designated data field of the user interface of the application 1002. The selection may be performed by the patient pressing an area of the touch screen 1002 of the personal mobile communication device 200a that corresponds to the medical information to be populated. The selection of the relevant medical information and/or fields, in some embodiments, causes the personal mobile communication device 200a to automatically populate at least a portion of the selected text (block 1916).

After the selected text is entered, the personal mobile communication device 200a determines whether additional associated medical information should be entered based on the selection of additional data fields in the user interface (decision block 1918). In some examples, the personal mobile communication device 200a operates a sequence or routine that provides prompts for the patient to select appropriate text and/or images to enter into the data fields. If there is additional associated medical information, as determined in decision block 1918, the procedure 1900 returns to blocks 1914-1916 where the patient specifies images and/or associated medical information for data field entry. If there is no additional associated medical information for entry, as determined in decision block 1918, the example procedure 1900 ends.

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

An exemplary application 1002 on the personal mobile communication device 200a is configured to accept images and/or text provided by the patient. In some embodiments, the application 1002 is configured to allow the patient to select text or photo input. If the patient selects 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 in one or more messages to the clinician server 200b. The application 1020 on the clinician server 200b determines the appropriate patient medical record in the database 1010 and finds a "notes" or free text field. The application 1020 stores the patient-provided text in the field. In some instances, 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.

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

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

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

The example data acquisition module 1104 of FIG. 11 is configured to format or otherwise structure the received information for population into one or more data fields of the patient's medical record. Generally, medical information received from a text message is unstructured. In other words, the text message does not provide a clear correlation or reference to a designed field of the patient's medical record. Instead, the data acquisition module 1104 is configured to determine the appropriate field for the medical information received within the text message.

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

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

In another embodiment, the data acquisition module 1104 prompts the patient through a sequence of messages (which may be defined by a routine or algorithm) to provide certain medical information. The sequence order may be known or defined and corresponds to a data field in the medical record. Thus, the data acquisition module 1104 automatically determines that a response to a prompt corresponds to a data field in the medical record associated with the prompt. For example, the data acquisition module 1104 transmits a text message prompting the patient for a "systolic blood pressure measurement." The data acquisition module 1104 determines that the response to the text includes a value for "systolic blood pressure measurement." The data acquisition module 1104 may analyze the received message to identify numeric values among other text and/or to compare values to acceptable ranges. After verifying that the patient has provided an acceptable response with medical information, the data acquisition module 1104 determines a subsequent message to send to the personal mobile communication device 200a based on the sequence of messages.

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

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

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

It should be understood that in other embodiments, the patient care template 2100 may include additional or fewer fields. For example, the template 2100 may additionally include data fields for pre-treatment and post-treatment patient weight, patient glucose level, and/or patient birth date. In another example, the template 2100 may include fields for fill rate, dwell time, drain or fluid removal rate, blood flow rate, outflow rate, ultrafiltration removal rate, dialysate removal rate, total dialysate infused, dialysate flow rate, pre-exchange flow rate, post-exchange flow rate, patient weight balance, return pressure, indication of excess patient fluid, filtration percentage, time remaining, dialysate concentration, dialysate name, patient identifier, room identifier, treatment area identifier, timestamp indicating when the data was generated, alarm conditions, alert conditions, and/or events.

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 including the text "Manual Exchange". In response, the data acquisition module 1104 identifies and selects the template 2100 for manual exchange. In another example, the patient may send a message to the data acquisition module 1104 via the personal mobile communication device 200a including the text "Pre-Treatment" or "Begin Treatment". In response, the data acquisition module 1104 identifies and selects a template for obtaining medical information needed before treatment is begun.

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

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

The patient medical template 2100 illustrated in FIG. 21 is configured to be stored on the clinician database 1010 and accessed by the clinician server 200b illustrated in FIGS. 10 and 11. Upon receiving a request to populate the template for a patient, the clinician server 200b is configured to copy or create an instance of the template 2100. The medical information received from the personal mobile communications device 200a is entered by the data acquisition module 1104 into the appropriate data fields 2102-2120 of the copy or instance of the template 2100. Once complete, the copy or instance is stored in the clinician database 1010 repository as the patient's medical record.

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

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 for the corresponding routine module 2152-2164 when the patient provides an image and/or text in a message. For example, while executing the routine module 2156 for blood pressure, the data acquisition module 1104 transmits a message prompting the personal mobile communication device 200a for a "systolic blood pressure measurement." The patient responds with a text message including an image of the screen or dial of the blood pressure monitor 104. The data acquisition module 1104 is configured to access a data template that corresponds to or is referenced by the routine module 1156 for blood pressure measurement. The data acquisition module 1104 then applies the data template and extracts text from the image using the procedures described above in connection with FIGS. 16-19 to identify relevant systolic blood pressure medical information for populating the blood pressure data field 2108 of the template 2100.

The exemplary routine 2150 may be configured to be initiated based on one or more messages received by the data acquisition module 1104 upon request from the patient. For example, the data acquisition module 1104 may receive a message with text including "Begin," "Start," and/or "Pre-treatment." Receipt of the message causes the data acquisition module 1104 to determine and initiate the routine 2150 for populating the data fields 2102-2120 of the template 2100. In another example, the data acquisition module 1104 transmits a first message defined by the routine 2150 to the patient at a predetermined time relative to the treatment. After receiving a response message with appropriate medical information from the personal mobile communication device 200a, the data acquisition module 1104 continuously transmits the messages defined by the routine 2150. In this manner, the data acquisition module 1104 controls the acquisition of medical information from the patient according to a predetermined sequence. The data acquisition module 1104 may not transmit the next message in the sequence defined by the routine 2150 until an appropriate response message is received from the personal mobile communications device 200a (and medical information is populated into the designated data fields 2102-2120 of the template 2100).

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

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

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

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

Once the medical information is received using routine 2150, the data acquisition module 1104 of the application 1020 uses data validation checks to ensure that the data is within acceptable ranges, correctly formatted, and/or in the 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 in the respective fields of the template 2100 and/or the patient's medical record. Once the data is in the appropriate format and units, the data acquisition module 1104 writes the medical information into the respective fields of the template 2100 and/or the patient's medical record.

In alternative embodiments, 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 which data fields are incomplete. In these alternative embodiments, the data acquisition module 1104 identifies the missing data and transmits one or more messages to the personal mobile communications device 200a to prompt the patient regarding the missing data.

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

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

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

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

The exemplary template processor 2204 is configured to identify messages from modules of routines (e.g., routine 2150) for transmission to the personal mobile communication device 200a. In some cases, the messages may be transmitted in a predetermined sequence to instruct or guide a clinician or patient through a process for populating a patient medical template. For example, the template processor 2204 may read module 2156 of routine 2150 of FIG. 21 and determine that a message should be transmitted that prompts the patient to record an image of the identifier 1012c of the scale 106. The template processor 2204 may be configured to wait until medical information associated with the identifier 1012c is received (to populate the data field 2106 of FIG. 21) before identifying a message from the routine module 2156 to be transmitted. In other cases, the template processor 2204 selects a message for transmission based on a message received from the personal mobile communication device 200a. For example, the processor 2204 may receive medical information associated with the identifier 1012c of the weighing scale 106. In response to the received medical information, the template processor 2204 may determine that the module 2154 corresponds to the received data and, accordingly, select a message prompting the patient to record an image of the screen of the weighing scale 104. As illustrated in FIG. 22, the personal mobile communication device 200a displays a text message from the template processor 2204 instructing the patient to record an image of the screen 2220 of the weighing scale 106.

In addition to sending the message, the template processor 2204 may be configured to select a data template. The data templates are stored in the 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 medical device type to the template processor 2204 via the message. Additionally, as discussed above, the template processor 2204 may receive images from the personal mobile communications device 200a, extract text from the images, and select an appropriate data template from the database 2208 to identify relevant medical information from the images, as described above.

In some embodiments, the template processor 2204 may receive a stream of messages from the personal mobile communications device 200a that includes substantially all of the medical information for the patient medical template 2100 or the patient's medical record. In these embodiments, the template processor 2204 reads the indicia, metadata, and/or device data field information provided with the data to determine the data fields of the template 2100 into which the data should be populated or written. The template processor 2204 may, for example, match the module's metadata or information (or the data fields 2102-2120 themselves) to the indicia, metadata, and/or device data field information provided with the medical information to determine the appropriate data fields of the template 2100.

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

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

The exemplary procedure 2300 is initiated in FIG. 23 when the clinician server 200b of FIGS. 10-12 and 22 receives a message 2301 (block 2302) from the personal mobile communication device 200a. The message 2301 indicates a request to initiate a treatment to be administered to the patient or to transmit 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 only provides completion of one type of template (e.g., a template for renal failure therapy), the message 2301 may indicate a request to initiate population of a blank template. In response to the message 2301, the clinician server 200b creates a copy of the patient medical template for data population.

After providing the patient medical template for data population, the clinician server 200b determines (using a routine associated with the template or by reading the template itself) at least one medical device for which medical information is needed and transmits a first camera message 2305 to the personal mobile communication device 200a accordingly (block 2306). The first camera message 2305 includes, for example, an instruction indicating that an image of the identifier 1012 of the medical device should be recorded. After some time, the clinician server 200b receives a message 2307 including medical information indicating the type of medical device (e.g., medical information from identifier 1012a) (block 2308). The clinician server 200b then determines a device data template (e.g., device data template 1700 of FIG. 17) based on the information included in the message 2307 or information defined in the patient's medical record (block 2310). For example, after determining that the message 2307 identifies 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).

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

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

23 by the personal mobile communication device 200a transmitting a message 2301 indicating a treatment to be administered to the patient or a request to begin inputting medical information (2352). The personal mobile communication device 200a then receives a camera message 2305 from the clinician server 200b. Information from the message 2305 is used by the personal mobile communication device 200a to display a prompt to the patient (block 2354). The prompt may specify, for example, that the medical device identifier 1012 should be imaged. The personal mobile communication device 200a then records an image of the medical device identifier 1012 based on input from the patient (block 2356). In some embodiments, the patient may enter text or select from a drop-down menu that specifies the medical device type/model if the identifier is not available or if the patient does not wish (or is unable) to record an image.

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

The personal mobile communication device 200a then receives a camera message 2313 from the server 200b with information for displaying a prompt to the patient to record an image of the screen (or other defined area) of the medical device (block 2360). The personal mobile communication device 200a responsively displays a prompt to the patient with the information needed to image the medical device. In response to the prompt, the patient uses the personal mobile communication device 200a to record an image of the screen (or other defined area) of the medical device (block 2362).

In FIG. 24, the example procedure 2350 continues by the personal mobile communication device 200a creating a text message with the captured image or text entered by the patient (block 2364). In some examples, the patient may modify or define the medical information. The personal mobile communication device 200a then transmits the message 2315 including the medical information or the image thereof (block 2366).

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

6. Manual/wireless/imaging medical information entry via web browser or file transfer
In some embodiments, the data acquisition module 1104 of FIG. 11 is configured to allow a patient to use his or her personal mobile communication device 200a to input medical information or provide images via a web browser or file transfer program. The web browser or file transfer program allows the personal mobile communication device 200a to provide medical information and/or images without using an application 1002. In this embodiment, the clinician server 200b hosts websites, APIs, and/or file transfer sites that are assigned addresses or uniform resource locators ("URLs"). The web browser or file transfer program on the personal mobile communication device 200a is configured to access the hosted websites, APIs, and/or file transfer sites and transmit the medical information.

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

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

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

25 shows a schematic diagram of a clinician server 200b hosting a website or file transfer site for receiving medical information via images from a personal mobile communication device 200a, according to an exemplary embodiment of the present disclosure. In the illustrated example, the personal mobile communication device 200a is running a web browser application 2500 that is directed to a website 2502 hosted by the clinician server 200b. The website 2502 includes a graphical user interface for entering medical information. In this example, the personal mobile communication device 200a records an image 1800 of the screen of the blood pressure monitor 104 of FIG. 10. The clinician server 200b applies a data template 1801 to the image and extracts a set of text, as shown in fields 1802, 1804, 1806, 1808, and 1810. The patient selects fields 1802, 1804, 1806, 1808, and 1810 where text should be entered into one or more selected data fields of the website 2502. In this manner, the clinician server 200b allows the patient to provide medical information via a website, a file transfer program, or an API.

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

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

The exemplary data access module 1106 may determine whether the medical and/or treatment information in the patient's medical record should be converted to a different format prior to transmission. For example, the medical and/or treatment information may be stored in the medical record in HL7 format. However, this format is not suitable for text messages and/or applications. The exemplary data access module 1106 determines the capabilities of the personal mobile communication device 200a to which the data should be transmitted. The data access module 1106 determines the capabilities based on registration information indicating whether the application 1002 is installed and/or whether the personal mobile communication device 200a is a feature-rich device. To view the medical information on the application 1002, the data access module 1106 uses one or more APIs to convert the medical and/or treatment information from the HL7 format, for example, to a HyperText Markup Language ("HTML") format, a Java 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 HL7 format, for example, via one or more APIs, to a text message or SMS message format. The example data access module 1106 thus allows patient medical record information to be viewed by patients regardless of the capabilities of their personal mobile communication device 200a.

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 communications device 200a. In these examples, the data access module 1106 provides medical information from one or more patient records for display in defined fields, graphs, etc. of one or more user interfaces provided by the application 1002. In some instances, fields from the medical records are referenced into fields of the user interface of the application 1002.

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

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

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

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, the patient can gauge how the treatment is progressing over time. Any deviations in treatment should be readily apparent and help persuade the patient to adhere to the prescribed regimen.

The exemplary user interface 2800 includes a calendar showing days when the patient was compliant with a treatment or therapy compared to days when the patient was non-compliant with the therapy. The patient may select one of those days to view additional medical information. For example, the user interface 2900 shows treatment or medical information for April 26th. The information includes a total amount of UF removed during that day, in addition to a breakdown of UF removed during manual exchanges compared to 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 compliant 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 may 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 to reflect the compliance or lack thereof.

In some examples, treatment information for manual exchanges is entered by the patient via the application 1002 on the personal mobile communication device 200a, while machine treatment information is received separately from the home therapy machine 90. In other examples, the user interface 2900 may display treatments performed at the patient's home and treatments performed at the clinic. The information may be organized based on the machine, program name, treatment type, prescription, etc. for which the information was received. The user interface 2900 in the illustrated example accordingly provides a single display of UF removed for the different exchanges, thereby providing patient information regarding the effectiveness of manual exchanges compared to machine-operated exchanges. The exemplary system 100 of FIG. 10 allows information from both exchanges to be stored together (based on date of treatment) for subsequent display and/or analysis.

2. Information Display Embodiment via Web Browser
In some embodiments, the personal mobile communication device 200a may not have the application 1002 installed. Instead, the patient may use a web browsing application to access a website or interface hosted by the clinician server 200b. In these embodiments, the data access module 1006 is configured to display the medical and/or treatment information in 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 the medical information in a web page. The data access module 1106 may be configured to format or render the medical and/or treatment information based on the web browser type and/or operating system of the personal mobile communication device 200a. In some instances, the data access module 1106 may request a username and password from the patient prior to providing access to the website.

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

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

4. Alarm/Alert Embodiments
In addition to providing a display of medical and/or treatment information, the example 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 alarms and/or alerts to the patient's personal mobile communication device 200a or the clinician device 152. In some embodiments, the data access module 1106 may include a rules table that specifies the devices to which certain alarms/alerts should be transmitted. Clinicians may use the clinician device 152 to subscribe to certain alarms/alerts and/or patients.

The data access module 1106 is configured to provide the alarm/alert 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 alarm/alert through an appropriate user interface of the application 1002. In some cases, the application 1002 is configured to display a notification indicating the alarm/alert. If the application 1002 is not installed, the data access module 1106 determines that the alarm and/or alert should be transmitted to the personal mobile communication device 200a via SMS or other text message.

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

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

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

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

In some embodiments, the alarm and/or alert may define conditions under which additional information should be prompted from the patient. In these embodiments, the data access module 1106 uses the 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 an additional weight or blood pressure measurement is sent to the patient's personal mobile communication device 200a. For example, the alarm or alert may define that a prompt for a new blood pressure measurement is required if the blood pressure value (or trend) exceeds a predetermined threshold. In another example, the alarm or alert may define that a prompt for a new blood pressure measurement is required if the accumulated fluid value or removed UF value (or trend) is outside of an acceptable range. In response, the data access module 1106 transmits a text message or notification via the application 1002 for the patient to perform and record a blood pressure measurement. In some cases, the application 1002 may open a user interface (e.g., user interface 3000 of FIG. 30) that prompts the patient to enter blood pressure information. If the additional data received from the personal mobile communication device 200a is not within an acceptable range, the data access module 1106 may escalate the alert to an alarm that is transmitted to the clinician device 152 and/or the personal mobile communication device 200a. Thus, the data access module 1106 is configured to operate rules that determine borderline patient conditions that require additional information from the patient before determining whether further attention or action is required from the clinician or patient.

In further embodiments, the rules of the data access module 1106 may instruct the patient to inspect the home therapy machine 90 and/or make changes thereto. In one example, the rules may specify that if treatment information has not been received from the home therapy machine 90 within a defined period (e.g., two days), the data access module 1106 should transmit an alert to the patient. In this situation, the patient may have provided medical information indicating that treatment has been administered, which the data access module 1106 uses to determine that an alert regarding adherence to treatment is not necessary. Instead, the data access module 1106 determines that an alert should be transmitted to the patient to check the network connection of the home therapy machine 90 so that treatment information stored on the machine 90 can be retrieved. The patient may respond to the alert using the personal mobile 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 send a ping message to the home therapy machine 90 regarding the missing treatment information. If a connection still cannot be made, the data access module 1106 may send an alert to the patient, clinician, and/or network administrator with more specific instructions to activate the home therapy machine 90 and/or to overcome the network connectivity problem.

In another example, the data access module 1106 may include one or more rules that specify that an alert should be generated in response to the therapy information being out of range. For example, a large difference between fluid fill and drain volumes may indicate a leak in the dialysis tubing or the connection to the patient. In response, the data access module 1106 transmits an alert to the patient prompting the patient to verify the fluid connections. The patient may provide a response indicating whether a leak was detected. In response, the data access module 1106 determines whether the leak was corrected in a subsequent therapy cycle (or primary sequence) or whether the tubing should be replaced. The data access module 1106 may determine similar consumable issues with cassettes, cartridges, etc. based on the therapy and/or medical information. For example, a low volume of UF removed may prompt the data access module 1106 to transmit an alert for the patient to verify the concentration of the dialysis fluid and/or concentrate connected to the home therapy machine 90.

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

The prescription and associated program are stored in an electronic prescription in 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. Programming may be performed locally via the clinician or patient, or remotely from the clinician server 200b. For example, the clinician server 200b (e.g., the therapy control module 1110) may transmit a copy of the prescription from the clinician database 1010 to the home therapy machine 90 after registration.

In some embodiments, the exemplary therapy control module 1110 is configured to operate in conjunction with the application 1002 on the personal mobile communication device 200a and/or the application on the clinician device 152 to allow the patient and/or clinician to select different prescription programs and/or prescriptions. FIG. 31 shows a schematic diagram of a user interface 3100 of the application 1002 that allows the patient to select between three different programs: a short-term program, a long-term program, and a weekend program. The patient may select a program based on their activity and/or status. In some embodiments, the application 1002 may display an alert from the data access module 1106 providing a recommendation to change the program based on a detected accumulation of fluid, weight gain, or higher blood pressure.

After the patient selects a different program via the user interface 3100, the application 1002 sends a message to the treatment control module 1110 indicating the selection. 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. Additionally, 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 related to the newly selected program. The home therapy machine 90 accordingly performs the next treatment based on the newly selected program. In some cases, the home therapy machine 90 may display a prompt for the patient to confirm the new program before acting according to the program.

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

In some embodiments, the therapy control module 1110 may send a notification to the clinician device 152 indicating that the patient wishes to change the program. The therapy 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 change the program and/or prescription via the therapy control module 1110 using his/her clinician device 152. In these embodiments, the therapy control module 1110 may send a message for display in the application 1002 of the personal mobile communication device 200a indicating the change in the program and/or that the clinician has made the change.

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

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

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

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

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

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

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

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

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

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

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

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

In some embodiments, the auxiliary module 1112 may determine that a communication session should be opened or may recommend opening a communication session. The auxiliary module 1112 may provide recommendations in conjunction with the data access module 1106 generating an alarm and/or alert. After detecting a condition related to an alert and/or alarm, the auxiliary module may identify clinician devices 152 that are available to join the session and then initiate a call to the personal mobile communication device 200a to address the alert and/or alarm. In one example, the auxiliary module 1112 may attempt to create a communication session after detecting that a patient's blood pressure, weight, accumulated fluid, etc., exceeds a predetermined threshold or changes significantly within a predetermined period of time.

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

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

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

Claims (20)

1. A system for transmitting information to a patient, the system comprising:
a home therapy machine for said patient configured to transmit therapy information;
a clinician database configured to store medical records and a registration file, the registration file (i) identifying the home therapy machine and the patient's personal device as registered devices, and (ii) identifying whether the personal device has an application installed for viewing the treatment information;
a clinician server communicatively coupled to the clinician database, the home therapy machine, and the personal device;
The clinician server includes:
storing said treatment information in said medical record;
receiving an indication that at least a portion of the treatment information is to 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 treatment information into an application format for display within the application;
transmitting the converted at least a portion of the treatment information to the personal device;
If the application is not installed,
converting said at least a portion of said medical information into a text message or short messaging service ("SMS") format;
transmitting the converted at least a portion of the treatment information to the personal device via one or more text or SMS messages. The system of claim 1, wherein the application format includes at least one of an Extensible Markup Language ("XML") format or a HyperText Markup Language ("HTML") format. The system of claim 1, wherein the indication 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. The system of claim 1, wherein the registration file is contained within the medical record. 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 from the personal device indicating a change from a first program to a second program;
2. The system of claim 1, configured to: transmit program instructions to the home therapy machine to change from the first program to the second program. The system of claim 1, wherein 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 weight scale, and a heart rate monitor. The system of claim 1, wherein the treatment information includes at least one of blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual exchange data, subjective data, or consumable data regarding a consumable item. The system of claim 7, wherein the consumable items include at least one of a filter, a blood line set, a dialysate concentrate container, a blood anticoagulant container, a drug container, a disposable cassette, a sorbent cartridge, and a water purification container. The system of claim 1, wherein the personal device is a personal mobile communication device. 1. A method for transmitting information to a patient, the method comprising:
storing a registration file in a clinician database, the registration file (i) identifying a home therapy machine and a personal device of the patient as registered devices, and (ii) identifying whether the personal device has an application installed for viewing treatment information;
receiving, at the clinician database, the treatment information from the home therapy machine for the patient;
storing said treatment information in said patient's medical record at said clinician database via a server;
receiving, at the server, an indication that at least a portion of the treatment information is to be displayed on the personal device;
determining, via the server, from the registration file, whether the application is installed on the personal device;
If the application is installed,
converting, via the server, the at least a portion of the treatment information into an application format for display within the application;
transmitting, via the server, the converted at least a portion of the treatment information to the personal device;
If the application is not installed,
converting, via the server, the at least a portion of the treatment information into a text message format or a short messaging service ("SMS") format;
transmitting, via the server, the converted at least a portion of the treatment information to the personal device via one or more text or SMS messages. The method of claim 10, wherein the application format includes at least one of an Extensible Markup Language ("XML") format or a HyperText Markup Language ("HTML") format. 11. The method of claim 10, wherein the indication 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. The method of claim 10, further comprising converting the treatment information via the server to Health Level 7 ("HL7") format prior to storing in the medical record. 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 from the personal device indicating a change from a first program to a second program;
11. The method of claim 10, further comprising: transmitting, via the server, to the home therapy machine, program instructions for changing from the first program to the second program. The method of 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 relating to a consumable item. 1. A system for transmitting information to a patient, the system comprising:
a clinician database configured to store medical records and a registration file, the registration file (i) identifying a home therapy machine and a personal device of the patient as registered devices, and (ii) identifying whether the personal device has an application installed for viewing treatment information from the home therapy machine;
a clinician server communicatively coupled to the clinician database, the home therapy machine, and the personal device;
The clinician server includes:
converting the therapy 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 indication that at least a portion of the converted treatment information is to be displayed at 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 transformed treatment information into an application format for display within the application;
transmitting the converted at least a portion of the treatment information to the personal device;
If the application is not installed,
converting the at least a portion of the converted medical information into a text message format or a short messaging service ("SMS") format;
transmitting the converted at least a portion of the treatment information to the personal device via one or more text or SMS messages. The system of claim 16, wherein the application format includes at least one of an Extensible Markup Language ("XML") format or a HyperText Markup Language ("HTML") format. The system of claim 16, wherein the indication 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. the personal device is a personal mobile communications device;
17. The system of claim 16, wherein 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 weight scale, and a heart rate monitor. The system of 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 a consumable item.