阅读说明：本技术 包括用于患者参与和治疗依从性的移动平台的医用流体输送系统 (Medical fluid delivery system including mobile platform for patient participation and therapy compliance ) 是由 德里克·威本森 克里斯托弗·丹尼尔·加斯曼 于 2019-09-05 设计创作，主要内容包括：公开了用于患者参与和治疗依从性的患者平台。在示例中,处理器被配置为从患者获得医疗信息以用于参与和治疗依从性跟踪。为了获得医疗信息,处理器使用户界面显示有要填写医疗信息的字段。在接收到对数据字段的选择之后,处理器提供从图像输入医疗信息的选项。如果选择了该选项,则处理器接收医疗设备的记录图像或医疗设备的屏幕、从图像中提取文本、使得能够选择来自图像的至少一部分文本,并且将所选择的来自图像的文本写入用户界面的数据字段中作为医疗信息。处理器将医疗信息传送到临床医生数据库中存储的患者病历。(A patient platform for patient participation and therapy compliance is disclosed. In an example, the processor is configured to obtain medical information from the patient for participation and therapy compliance tracking. To obtain the medical information, the processor causes the user interface to display fields to be filled in with the medical information. After receiving a selection of a data field, the processor provides an option to input medical information from the image. If the option is selected, the processor receives a recorded image of the medical device or a screen of the medical device, extracts text from the image, enables selection of at least a portion of the text from the image, and writes the selected text from the image into a data field of the user interface as medical information. The processor communicates the medical information to patient medical records stored in a clinician database.)

1. A machine-accessible device having instructions stored thereon that are configured to, when executed, 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;

operating a connection interface configured to connect to a clinician database configured to store patient medical records; and

Operating a processor to obtain medical information by:

displaying, via the display interface, a user interface having fields to be filled in with medical information,

upon 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 entry,

if the first option is selected:

receiving a recorded image from the camera, the recorded image comprising a medical device or a screen of a medical device,

-extracting a text from said image,

enabling selection of at least a portion of the text from the image via the display interface, an

Writing the text selected from the image as the medical information into the data field of the user interface, an

Enabling text entry of the data field as medical information via the display interface if the second option is selected, and

upon receiving a send instruction, the medical information written to the data field is transferred to a patient medical record stored in the clinician database.

2. The machine-accessible device of claim 1, further comprising instructions stored thereon configured, when executed, to cause the machine to operate the processor to:

determining a data template for the extracted text on the image;

processing the extracted text using the data template to group the extracted text into fields; and

enabling selection of at least one of the fields to write the text selected from the image to the data field of the user interface.

3. The machine-accessible device of claim 2, wherein the data template is configured to:

specifying a context for the extracted text in relation to a text location within the image.

4. The machine-accessible device of claim 2 further comprising instructions stored thereon configured, when executed, to cause the machine to operate the processor to determine the data template based on at least one of:

(i) a selection of a medical device type via the user interface,

(ii) information scanned from an identifier located on the medical device, an

(iii) Labels within the extracted text, or

(iv) Relative layout of the extracted text.

5. The machine-accessible device of claim 4 wherein the identifier located on the medical device comprises 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.

6. The machine-accessible device of claim 1, wherein the medical device includes at least:

renal failure therapy machines, infusion pumps, oxygen sensors, respiration monitors, blood glucose meters, blood pressure monitors, ECG monitors, weight scales, and heart rate monitors.

7. The machine-accessible device of claim 1 wherein the data field of the user interface is configured to receive at least one of:

blood pressure measurement data, pulse data, weight data, glucose data, temperature data, manual exchange data for renal failure, subjective data, or consumption data related to consumables.

8. The machine-accessible device of claim 7 wherein the consumable comprises at least one of:

A filter, a blood line set, a dialysate concentration container, a blood anticoagulant container, a drug container, a disposable cartridge, an adsorbent cartridge, and a water purification container.

9. The machine-accessible device of claim 1,

the machine is a personal mobile communication device.

10. A method for populating a patient medical record of a clinical database using images of records, the method comprising:

transmitting a first message to a personal device, the first message prompting a patient to use a camera of the personal device to record a first image of a medical device;

receiving the first image from the personal device;

determining, via a processor, first medical information indicative of a type or model of the medical device from the first image;

determining, via the processor, a data template and a second message associated with the determined type or model of the medical device;

transmitting, via the processor, the second message to the personal device prompting the patient to use the camera to record a second image of the screen of the medical device;

receiving, via the processor, the second image from the personal device;

Extracting, via the processor, text from the second image;

processing, via the processor, the extracted text using the data template to group the extracted text into fields; and

writing, via the processor, at least some of the text in at least one of the fields to the patient medical record.

11. The method of claim 10, further comprising:

determining, via the processor, a correspondence between one of the fields and a record field in the patient medical record; and

writing, via the processor, at least some of the text from the fields to the record fields in the patient medical record.

12. The method of claim 10, further comprising:

determining, via the processor, a treatment time from the patient medical record; and

transmitting, via the processor, the first message prior to the treatment time.

13. The method of claim 10, further comprising:

receiving, in the processor, a therapy message from the personal device indicating that the patient is to begin therapy; and

transmitting, via the processor, the first message prior to starting the treatment.

14. The method of claim 10, wherein,

receiving in the processor the first image via a first text message or a first short message service ("SMS") message, an

Receiving, in the processor, the second image via a second text message or a second SMS message.

15. The method of claim 10, further comprising:

converting, via the processor, at least some of the text from at least one of the fields to a Health-Level-7 ("HL 7") format prior to writing to the patient medical record.

16. The method of claim 10, further comprising:

comparing, via the processor, at least some of the text from at least one of the fields to a predetermined range; and

writing, via the processor, at least some of the text from at least one of the fields if the at least some of the text from at least one of the fields is within the predetermined range.

17. A system for communicating information to a patient, the system comprising:

a home therapy apparatus of the patient, the home therapy apparatus configured to transmit therapy information;

A clinician database configured to store medical records and a registry file, the registry file identifying the home therapy device and the personal device of the patient as registry devices, and the registry file identifying whether the personal device has an application installed for viewing the therapy information and the medical information;

a clinician server communicatively coupled to the clinician database, the home therapy device, and the personal device, the clinician server configured to:

storing the treatment information and the medical information to the medical record;

receiving an indication that at least some of the therapy information and the medical information are to be displayed on the personal device;

determining from the registry file whether the application is installed on the personal device;

if the application is installed:

converting the at least some of the treatment information and the medical information into an application format for display within the application, an

Transmitting at least some of the converted therapy information and the medical information to the personal device, and

if the application is not installed:

Converting said at least some of said treatment information and said medical information into a text message or short message service ("SMS") format, and

transmitting the converted at least some of the therapy information and the medical information to the personal device via one or more text messages or SMS messages.

18. 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.

19. The system of claim 17, wherein the indication that at least some of the therapy information and the medical information are to be displayed on the personal device comprises:

at least one of a message from the application or a text/SMS message from the personal device.

20. The system of claim 17, wherein,

the registration file is included within the medical record.

21. The system of claim 17, wherein the home therapy device is configured to store a prescription having two programs, each program providing parameters for operating the home therapy device to perform a therapy, and,

wherein the clinician server is configured to:

Receiving a program message from the personal device indicating a change from a first program to a second program; and

transmitting a program instruction to the home treatment appliance to change from the first program to the second program.

Background

Currently, it is a nearly impossible task to make contact with a patient for a long time outside of a medical environment. Many patients are generally initially more robust, similar to starting to become a gym member or purchasing a treadmill. For example, initially, patients are readily receptive to medical treatments (e.g., medical fluid delivery treatments) that are performed by themselves in the patient's home. For treatment, the patient must attach himself to a medical fluid delivery machine (or a container containing a renal failure treatment fluid) to remove the build-up of toxins from the blood. Part of the treatment may include tasks that the patient has to perform, such as weighing himself, measuring his blood pressure and/or recording information related to his treatment. The information recorded by the patient is typically reviewed by a clinician to ensure that the treatment is prescribed. The clinician may also review the recorded data to determine if adjustments to the treatment are needed.

Over time, many patients become less enthusiastic with respect to treatment due to loss of freshness, simply becoming another obligation. It is conceivable that the patient would prefer to perform more exciting, relaxing or stimulating activities than self-administered medicine. As patients continue treatment, they sometimes begin to omit performing other tasks related to treatment. Omitting other tasks and reducing enthusiasm for treatment may create gaps in clinical supervision of ongoing treatment. As the patient moves further out of treatment, they may begin to skip treatment or abandon treatment altogether, risking health in the process.

Disclosure of Invention

Technical problem

Medical fluid data transfer systems including a mobile platform are disclosed herein. The medical fluid data transfer system is configured to improve participation and/or treatment compliance with a patient through interaction provided by the patient's portable device (e.g., cell phone, smartphone, tablet, etc.). In particular, the medical fluid data transmission system provides enhanced feedback and control to the patient (without being overwhelmed), which makes the patient feel as if he or she is controlling his or her therapy rather than following the clinician's instructions. For example, a personal mobile communication device of a medical fluid data transmission system may display treatment information and/or vital sign data of a patient. The personal mobile communication device may also enable the patient to switch between different prescribed treatments or procedures without having to directly program the medical fluid delivery machine. Patients who feel in control are more likely to continue to receive treatment.

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

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

The medical fluid data transmission systems and methodologies of the present disclosure may be applied to fluid delivery, for example, in the following areas: plasmapheresis, hemodialysis ("HD"), hemofiltration ("HF"), hemodiafiltration ("HDF"), and continuous renal replacement therapy ("CRRT") treatments. The medical fluid data transfer system described herein is also suitable for peritoneal dialysis ("PD"), intravenous drug delivery, and nutrient delivery. These modalities may be referred to herein collectively or generally individually as medical fluid delivery or treatment.

The above-described approaches may be provided by a medical fluid delivery machine that houses components required for delivery of a medical fluid, such as one or more pumps, valves, heaters (if needed), on-line medical fluid generation equipment (if needed), sensors (such as one or more or all of pressure sensors, conductivity sensors, temperature sensors, air detectors, blood leak detectors, etc.), a user interface, and a control unit, which may employ one or more processors and memory to control the above-described equipment. The medical fluid delivery machine may also include one or more filters, such as a dialyzer or hemofilter for cleaning blood and/or an ultrafilter for purifying water, dialysate, or other fluids.

The medical fluid delivery machines and medical fluid data transfer systems and methods described herein may be used with home-based machines. For example, these systems may be used with home HD, HF, or HDF machines that operate at the convenience of the patient. One such Home System is described in U.S. patent No.8,029,454 ("the 454 patent"), filed on day 11, month 4, 2004, published on day 2011, entitled "High connection Home hepatology/telematics And Sorbent System" And assigned to the assignee of the present application. Other such home systems are described in U.S. patent No.8,393,690 entitled "closure for a Portable hemilysis System" filed on day 27 of 2008, 8 and 12 of 2013 (the "690 patent"). Each of the above references is incorporated herein by reference in its entirety.

As described in detail below, the medical fluid data transfer systems and methods of the present disclosure may operate within an encompassing platform system that includes a plurality of machines, including many different types of devices, patients, clinicians, doctors, service personnel, electronic medical record ("EMR") databases, websites, resource planning systems that process data generated via patient and clinician communications, and business intelligence. The medical fluid data transmission systems and methods of the present disclosure operate seamlessly throughout the system and without violating its rules and protocols.

Technical scheme

In a first aspect of the disclosure, which may be combined with any other aspect listed herein unless otherwise stated, a machine accessible device having instructions stored thereon configured to, when executed, cause a machine to fill out a patient medical record of a clinical system by: operating a camera to record an image; operating a display interface; operating a connection interface configured to connect to a clinician database configured to store patient medical records; and operating the processor to obtain the medical information. Operating the processor to obtain medical information by: displaying, via the display interface, a user interface having fields to be filled in with medical information, and upon selection of a data field of the user interface, graphically providing, via the display interface, a first option to input medical information from an image and a second option to input medical information via text entry. If the first option is selected, the processor receives a recorded image from the camera, the recorded image including a medical device or a screen of a medical device, extracts text from the image, enables selection of at least a portion of the text from the image via the display interface, and writes the text selected from the image as the medical information in a data field of the user interface. If the second option is selected, the processor enables text entry of the data field via the display interface as medical information. The processor is also operative to obtain medical information by transferring the medical information written to the data fields to patient histories stored in the clinician database after receiving the send instruction.

According to a second aspect of the disclosure, which may be used in combination with any other aspect listed herein, unless stated otherwise, the machine-accessible device further includes instructions stored on the device configured to, when executed, cause the machine to operate the processor to: determining a data template for the text extracted from the image; processing the extracted text using the data template to group the extracted text into fields; and enabling selection of at least one of the fields to write text selected from the image to the data field of the user interface.

According to a third aspect of the present disclosure, which may be used in conjunction with any other aspect listed herein, unless otherwise specified, the data template is configured to specify context to the extracted text in relation to a text position within the image.

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

According to a fifth aspect of the present disclosure, which may be used in combination with any other aspect listed herein, unless otherwise specified, the identifier located on the medical device comprises 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 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 listed herein, unless otherwise specified, the medical devices include at least renal failure therapy machines, infusion pumps, oxygen sensors, respiration monitors, blood glucose meters, blood pressure monitors, ECG monitors, weight scales, and heart rate monitors.

According to a seventh aspect of the present disclosure, which may be used in combination with any other aspect listed herein, unless otherwise specified, the data field of the user interface is configured to receive at least one of: blood pressure measurement data, pulse data, weight data, glucose data, temperature data, manual exchange data for renal failure, subjective data, or consumption data related to consumables.

According to an eighth aspect of the present disclosure, which may be used in combination with any other aspect listed herein, unless otherwise specified, the consumable comprises at least one of: a filter, a blood line set, a dialysate concentration container, a blood anticoagulant container, a drug container, a disposable cartridge, an adsorbent cartridge, and a water purification container.

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

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

According to an eleventh aspect of the present disclosure, which may be used in combination with any other aspect listed herein, unless otherwise specified, the method further comprises: determining, via the processor, a correspondence between one of the fields and a record field in the patient medical record; and writing, via the processor, at least some text from the field to a record field in the patient medical record.

According to a twelfth aspect of the disclosure, which may be used in combination with any other aspect listed herein, unless otherwise specified, the method further comprises: determining, via the processor, a treatment time from the patient medical record; and transmitting, via the processor, the 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 listed herein, unless otherwise specified, the method further comprises: receiving, in the processor, a therapy message from the personal device indicating that the patient is to begin therapy; and transmitting, via the processor, the first message prior to starting treatment.

According to a fourteenth aspect of the present disclosure, unless otherwise specified, which may be used in conjunction with any other aspect listed herein, the first image is received in the processor via a first text message or a first short message service ("SMS") message, and the second image is received in 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 listed herein unless otherwise specified, the method further comprises converting, via the processor, at least some text from at least one field to a Health-Level-7 ("HL 7") format prior to writing the patient medical record.

According to a sixteenth aspect of the present disclosure, which may be used in combination with any other aspect listed herein, unless otherwise specified, the method further comprises: comparing, via the processor, at least some text from at least one field to a predetermined range; and writing, via the processor, at least some text from at least one field if the at least some text from the at least one field is within the predetermined range.

According to a seventeenth aspect of the present disclosure, which may be used in combination with any other aspect listed herein unless stated otherwise, a system for communicating information to a patient, comprising: a home therapy apparatus of a patient, the home therapy apparatus configured to transmit therapy information; and a clinician database configured to store medical records and a registry file identifying the home therapy apparatus and the personal device of the patient as registered devices and identifying whether the personal device has an application installed for viewing the therapy information and the medical information. The system also includes a clinician server communicatively coupled to the clinician database, the home therapy device, and the personal device. The clinician server is configured to: storing the treatment information and the medical information in the medical record; receiving an indication that at least some of the therapy information and the medical information are to be displayed on the personal device; and determining from the registry file whether the application is installed on the personal device. If the application is installed, the clinician server is configured to convert at least some of the therapy information and the medical information into an application format for display within the application, and to transmit the converted at least some therapy information and medical information to the personal device. If the application is not installed, the clinician server is configured to convert at least some of the therapy information and the medical information into a text message or short message service ("SMS") format and to send the converted at least some therapy information 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 listed herein, unless otherwise specified, 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 listed herein, unless otherwise specified, displaying on the personal device at least some of the therapy information and the indication in the medical information includes at least one of a message from the application or a text/SMS message from the personal device.

According to a twentieth aspect of the disclosure, which may be used in combination with any other aspect listed herein, the registry file is included within the medical record, unless otherwise specified.

According to a twenty-first aspect of the present disclosure, which may be used in combination with any other aspect listed herein, unless stated otherwise, the home therapy apparatus is configured to store a prescription having two programs, each program providing parameters for operating the home therapy apparatus to perform a therapy, and the clinician server is configured to: receiving a program message from the personal device indicating a change from a first program to a second program; and sending program instructions to the home treatment appliance to change from the first program to the second program.

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

Advantageous effects

In view 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.

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

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

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

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

Another advantage of the present disclosure is to provide medical fluid data transmission systems and methods that can be applied to different types of medical fluid delivery machines.

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

Further, an advantage of the present disclosure is to reduce the waste of disposable kits and other ancillary soft goods due to the discarding that typically occurs when the machine timer expires.

The advantages discussed herein may be found in one or some, and perhaps not all, of the embodiments disclosed herein. Additional features and advantages are described herein, and will be apparent from, the following detailed description and the figures.

Drawings

Fig. 1 is a schematic diagram illustrating one embodiment of a system for medical fluid data transfer incorporating a medical fluid delivery machine of the present disclosure so that data may be transferred between the machines in accordance with an embodiment of the present disclosure.

Fig. 2 is a schematic view of one embodiment of a medical fluid delivery machine of the present disclosure.

Fig. 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 view of one embodiment of a medical fluid delivery machine and data transmission system and method of the present disclosure.

Fig. 5 is a schematic view of a second embodiment of the medical fluid delivery machine and data transmission system and method of the present disclosure.

Fig. 6 is a schematic view of a third embodiment of a medical fluid delivery machine and data transmission system and method of the present disclosure.

Fig. 7 is a schematic diagram of one embodiment of a hospital or clinical version of the medical fluid delivery device and data transmission system and method of the present invention with the 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 medical fluid delivery device and data transmission system and method of the present invention with the 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 medical fluid delivery device and data transmission system and method of the present disclosure with the mobile communication device application in a third state.

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

Fig. 11 shows a diagram illustrating operational modules of an application at a clinician server of the medical fluid data transmission system of fig. 10, in accordance with an embodiment of the present disclosure.

Fig. 12 shows a diagram illustrating communication between the home therapy apparatus, the personal mobile communication device, and the clinician server of fig. 10 and 11, according to an example embodiment of the present disclosure.

Fig. 13 illustrates an example patient data structure stored on a clinician database of the medical fluid data transmission system of fig. 10 according to an example embodiment of the present disclosure.

Fig. 14 and 15 show diagrams illustrating a user interface of the application of fig. 11, according to example embodiments of the present disclosure.

Fig. 16 is a schematic diagram of the personal mobile communication device of fig. 10 and 11, according to an example embodiment of the present disclosure.

Fig. 17 shows a schematic diagram of a data template according to an example embodiment of the present disclosure.

FIG. 18 shows a diagram illustrating writing to data fields of the user interface of FIG. 14, according to an example embodiment of the present disclosure.

Fig. 19 is a flowchart of an example process for inputting medical information from an image using an application of the personal mobile communication device of fig. 10 and 11, according to an example embodiment of the present disclosure.

Fig. 20 shows an example of a user interface that may be displayed by an application on the personal mobile communication device of fig. 10 and 11 to enable a patient to provide a recorded image, according to an example embodiment of the present disclosure.

Fig. 21 shows a schematic diagram of a patient medical template used by the clinician server of fig. 10 and 11 to fill in data fields of a medical record of a patient, according to an example embodiment 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 example embodiment of the present disclosure.

Fig. 23 and 24 are flowcharts of an example process for populating the medical device template of fig. 21 using images recorded by the personal mobile communications device of fig. 10 and 11 (and/or text messages received from the personal mobile communications device of fig. 10 and 11), according to an example embodiment of the present disclosure.

Fig. 25 shows a diagram of a clinician server hosting a website or file transfer site to receive medical information via images from the personal mobile communication device of fig. 10 and 11, according to an example embodiment of the present disclosure.

Fig. 26-29 illustrate diagrams of a personal mobile communication device displaying medical information provided by the clinician server of fig. 10 and 11, according to example embodiments of the disclosure.

Fig. 30 shows a diagram of the personal mobile communication device of fig. 10 and 11 prompting a patient to enter medical information, according to an example embodiment of the present disclosure.

Fig. 31 shows a diagram of the personal mobile communication device of fig. 10 and 11 providing a patient with a procedure selected for medical treatment, according to an example embodiment of the present disclosure.

Fig. 32 shows a diagram of the personal mobile communication device of fig. 10 and 11 providing educational content to a patient, according to an example embodiment of the present disclosure.

Fig. 33 shows a diagram of the personal mobile communication device of fig. 10 and 11 providing a video chat session between a patient and a clinician according to an example embodiment of the present disclosure.

Detailed Description

Medical fluid delivery systems are disclosed herein. An example medical fluid delivery system is configured to improve patient involvement in a medical treatment, such as a medical fluid delivery treatment. The medical fluid delivery system is configured to provide the patient with more transparency and at least some control over their treatment to guide their treatment, while providing resources to educate or otherwise assist the patient throughout the treatment. The example medical fluid delivery system is configured to provide patient participation regardless of the type or set of functional components of the medical device that are relevant to the patient's treatment or personal mobile communication device. Such a configuration makes the disclosed medical fluid delivery system compatible with virtually any patient situation.

In some embodiments, a medical fluid delivery system includes a personal mobile communication device, a medical fluid delivery machine, and a clinician server/database. Example personal mobile communication devices and medical fluid delivery machines are located in a patient's home and/or in a self-service medical facility. The clinician server is communicatively coupled to the personal mobile communication device and/or the medical fluid delivery machine via a wide area network (i.e., the internet). The clinician server is configured as a hub that enables the personal mobile communication device to provide functionality designed for participation by patients in medical fluid delivery treatments.

As disclosed herein, an example clinician server receives medical fluid delivery data (e.g., therapy information) from a medical fluid delivery machine, which is stored in one or more patient records in a clinician database. The clinician server provides the personal mobile communication device with access to medical fluid delivery data to enable the patient to track treatment progress. In addition, the patient may use the personal mobile communication device to change the treatment procedure (or request a change in the treatment procedure). The request is sent by the clinician server to verify that the change is appropriate prior to transmission to the medical fluid delivery machine.

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

As disclosed herein, a personal mobile communications device may include a feature-rich smart device, such as a smartphone or tablet. The smart device may operate a dedicated application (e.g., "app") defined by instructions stored in memory. Execution of the stored instructions may result in the smart device executing a process of the application configured to increase patient engagement with medical care. In some cases, the personal mobile communication device may include a reduced-functionality conventional cellular telephone that contains considerably less processing power and functionality than a smart device. The cellular device may operate using text messages and/or a dedicated application (e.g., App) defined by instructions stored in memory. Applications for reduced functionality devices may have less functionality than applications for smart devices.

The following disclosure is divided into two parts. The first section discloses embodiments of a medical fluid delivery system. The second section discloses features that enable medical fluid delivery systems to increase patient involvement and/or compliance with medical treatments.

I. Medical fluid delivery System embodiments

An example medical fluid delivery system includes one or more medical fluid delivery machines. One example of a medical fluid delivery device is a renal failure therapy apparatus. With respect to renal failure therapy devices, the renal system of a patient may fail for a variety of reasons. Renal failure causes several physiological abnormalities. 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, etc.) accumulate in blood and tissues.

Renal failure and reduced kidney function are treated by dialysis. Dialysis can remove waste, toxins and excess water from the body that a properly functioning kidney will remove. Dialysis therapy to replace kidney function is of vital importance to many people because such therapy can save lives.

One type of renal failure treatment is hemodialysis ("HD"), which typically uses diffusion to remove waste products from a patient's blood. Diffusion gradients occur across the semipermeable dialyzer between the blood and electrolyte solutions, known as dialysate, causing diffusion.

Hemofiltration ("HF") is an alternative renal replacement therapy that relies on convective transport of toxins in the patient's blood. HF is achieved by adding a substitution or replacement fluid (typically 10 to 90 liters of such fluid) to the extracorporeal circuit during treatment. During HF treatment, substitution fluid and fluid accumulated by the patient during treatment are ultrafiltered, providing a convective transport mechanism that is particularly advantageous for removing mesogens and macromolecules (in hemodialysis, small amounts of waste products are removed and fluid is obtained between dialysis procedures, however, the solute resistance to removal of ultrafiltrate is not sufficient to provide convective clearance).

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

Most HD (HF, HDF) treatments occur centrally. Today, there is a trend toward home hemodialysis ("HHD"), in part because HHD can be performed daily, which has therapeutic advantages over central hemodialysis treatments, which are typically performed every two or three weeks. Studies have shown that frequent treatments can remove more toxins and waste products than patients receiving less frequent but possibly longer treatments. Patients who are treated more frequently do not experience as many cycles of decline as patients who are treated centrally, which have accumulated two to three days of toxin prior to treatment. In some regions, the nearest dialysis center may be several miles away from the patient's home, resulting in home treatment time that consumes a large portion of the day. HHD may occur during the night or during the day when the patient is resting, working, or otherwise engaged in production.

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

Peritoneal dialysis treatments are of various types, including continuous ambulatory peritoneal dialysis ("CAPD"), automated peritoneal dialysis ("APD"), and tidal flow dialysis and continuous flow peritoneal dialysis ("CFPD"). CAPD is a manual dialysis treatment. Here, the patient manually connects the implanted catheter to the drain to allow the spent or spent dialysate to drain from the peritoneal cavity. The patient then connects the catheter to a bag of fresh dialysate to infuse fresh dialysate through the catheter into the patient. The patient disconnects the catheter from the fresh bag of dialysate and retains the dialysate within the peritoneal cavity, where the transfer of waste, toxins and excess water takes place. After a dwell period, the patient repeats the manual dialysis procedure, for example four times a day, with each treatment lasting about one hour. Manual peritoneal dialysis requires a significant amount of time and effort by the patient, and therefore has ample room for improvement.

Automated peritoneal dialysis ("APD") is similar to CAPD in that dialysis treatment involves drainage, filling and dwell cycles. However, APD machines typically automatically perform a cycle when a patient falls asleep. The APD machine eliminates the need for the patient to manually perform a treatment cycle and to transport supplies during the day. The APD machine is fluidly connected to the implanted catheter, a source or bag of fresh dialysate, and a drain. The APD machine pumps fresh dialysate from a dialysate source through a catheter to the peritoneal cavity of a patient. The APD machine also allows dialysate to be retained within the chamber and the transfer of waste, toxins and excess water to take place. The source may include a plurality of sterile dialysate bags.

The APD machine pumps used or spent dialysate from the peritoneal cavity through a catheter to a drain tube. As with manual procedures, several cycles of emptying, filling and dwell occur during dialysis. The "last fill" occurs at the end of the APD and remains in the peritoneal cavity of the patient until the next treatment is performed.

Any of the above-described manners performed by the machine may be run as planned, and may require a startup process. For example, dialysis patients are typically treated as planned, such as every other day, every day, and so forth. Blood treatment apparatus usually require a certain amount of time to set up, e.g. run a disinfection process, before treatment. Patients receiving the above approach may be over a busy life and the project to be performed or the task scheduled to be completed on the day of treatment.

The great appeal of home treatment to patients surrounds the flexibility in lifestyle provided by allowing a patient to schedule treatment in his or her home largely according to his or her own schedule. However, home medical fluid delivery machines may include software timers that indicate and restrict a user or patient. Home hemodialysis systems may, for example, require a patient to be in close proximity to a home hemodialysis machine to initiate a pre-treatment, during treatment, and post-treatment sequence.

In one particular example, a home therapy device may reuse certain components by sterilizing them between treatments. The machine may employ one or more sterilization timers that require the patient or caregiver to use the machine to begin treatment before the sterilization timer expires. Otherwise, the patient would have to wait until another sterilization procedure is completed before treatment can begin. In an embodiment, the home therapy apparatus communicates a therapy start time deadline via a graphical user interface of the machine, which requires the patient to approach the machine to access the start time deadline and to react accordingly.

It should be understood that the present disclosure is applicable to any type of sterilization, such as hot water sterilization and chemical sterilization. In this regard, the present disclosure is not limited to home treatment devices, for example, machines in the center are typically chemically sterilized and a treatment start time limit may be set after such sterilization. Furthermore, the present disclosure is not limited to start time periods based on sterilization, but may also be applied to other start time periods, for example, start time periods based on the completion of perfusion. Still further, the present disclosure is not limited to an initial start time period. For example, most machines will allow the patient to temporarily stop treatment and disconnect from the machine to perform some type of necessary action away from the machine. For blood treatments, the machine will typically flush blood back to the patient, and may or may not circulate dialysate for a period of time. In either case, the time that the patient may be temporarily disconnected from the machine is not infinite, and it is contemplated that the present disclosure is also applicable to return time limits.

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

It is envisaged that the communication software may alternatively or additionally be configured to automatically program reminders on the user's mobile communication device, for example on the device's native task tracking function (such as a calendar application). Most smartphones are equipped with a calendar that divides each day into a number of periods, such as hours. The software of the system and method of the present disclosure may be programmed to access the smartphone calendar of the authorized patient and/or caregiver and fill in the appropriate time of day with the appropriate information, e.g., the time period during which the machine should begin or complete sterilization.

In one embodiment, communications from the software systems and methods of the present disclosure are unidirectional. For example, the communication may be a mobile communication device from a medical fluid delivery machine (possibly a home machine) to a patient or caregiver. In an alternative embodiment, the software systems and methods of the present disclosure enable two-way communication between a medical fluid delivery machine and a mobile communication device of a patient or caregiver. In one example, two-way communication may allow a patient or caregiver to remotely initiate certain machine routines using their mobile communication device. One example routine is an automated self-test routine that may be executed without any user interaction with the system, other than an initialization or startup sequence. The remote start-up sequence may benefit the patient or caregiver, for example, by providing additional time for the patient or caregiver to perform other tasks, away from the machine. Communication becomes bidirectional when the machine initiates communication by indicating that the machine is ready to perform a self-test routine. The patient or caregiver responds to the machine via the software systems and methods of the present disclosure at a desired time to initiate the sequence.

For the software of the system and method of the present disclosure, it is contemplated that communication between the patient and/or caregiver and the machine is disabled as long as the machine is in the "patient connected" software state. For example, if a clinician attempts to send a command to a machine that is currently treating a patient, the command may be intercepted by the middleware software application so that the command is not transmitted to the machine. The middleware software application may then pass back to the clinician that the machine is busy and does not accept communications.

The examples described herein are applicable to any medical fluid delivery system that delivers medical fluids such as blood, dialysate, replacement fluid, or/and intravenous ("IV") medications. These examples are particularly suitable for renal failure treatments, such as all forms of hemodialysis ("HD"), hemofiltration ("HF"), hemodiafiltration ("HDF"), continuous renal replacement therapy ("CRRT"), and peritoneal dialysis ("PD"), collectively or collectively referred to herein as renal failure treatment. The medical fluid delivery machine may alternatively be a drug delivery or nutritional fluid delivery device, such as a high capacity peristaltic-type pump or a syringe pump. The machine described herein may be used in a domestic setting. For example, a machine operating with the data transmission scheme of the present disclosure may be used with a home HD machine that may be running, for example, at night while a patient is sleeping. The medical fluid data transfer systems and methods 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 transmission system 10 operating within a medical fluid delivery machine 90 is illustrated. The system 10 includes a number of medical fluid delivery machines 90 (one of which is discussed in detail below). The machines 90 of the data transmission system 10 may be of the same type (e.g., all HD machines) or of different types (e.g., a mix of HD, PD, CRRT, and medical or nutritional fluid delivery).

Although a single medical fluid delivery device 90 is shown in communication with connection server 118, system 10 oversees the operation of multiple medical fluid delivery systems and machines of the same or different types listed above. For example, there may be M hemodialysis machines 90, N hemodialysis machines 90, O CRRT machines 90, P peritoneal dialysis machines 90, Q home medication conveyors 90, R nutrition or medication conveyors 90 connected to the server 118 and operating with the system 10. The numbers M to R may be the same or different numbers, and may be 0, 1, or greater than 1. In fig. 1, the medical fluid delivery device 90 is shown as a home therapeutic device 90 (shown in phantom for home use).

The household therapeutic apparatus 90 can be arrangedThe front end thereof receives purified water from the water treatment apparatus 60 as described above. In one embodiment, the water treatment device 60 is connected to the home treatment apparatus 90 via an Ethernet cable. The home treatment device 90 in the illustrated embodiment operates with devices other than the water treatment device 60, such as a blood pressure monitor 104, a weight scale (e.g., a wireless weight scale 106), and a user interface (such as a wireless tablet user interface 122). In one embodiment, the home therapy device 90 is wirelessly connected to the server 118 via the modem 102. Each of these components may (but need not) be located in the patient's home, as shown in dashed lines in fig. 1. Any one or more or all of the components 60, 104, 106, and 122 may be in wired or wireless communication with the home therapy device 90. The wireless communication may be via Bluetooth ^TM、WiFi^TM、Wireless universal serial bus ("USB"), infrared, or any other suitable wireless communication technology. Alternatively, any one or more or all of the components 60, 104, 106, and 122 may communicate with the home therapy device 90 via wired communication.

The connection server 118 communicates with the medical fluid delivery machine 90 via a medical equipment system hub 120. The system hub 120 enables data and information about each therapeutic home appliance 90 and its peripherals to be disseminated back and forth between the appliances 90 and other clients connected to the server 118 via the connection server 118. In the illustrated embodiment, the system hub 120 is connected to a services 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 records database maintained, for example, at a clinic or hospital 126a through 126 n.

An electronic medical record ("EMR") database at the clinic or hospital 126 a-126 n stores electronic information about the patient. The system hub 120 may send data collected from the log file of the machine 90 to the hospital or clinic databases 126a through 126n to consolidate or supplement the patient's medical records. Databases of clinics or hospitals 126 a-126 n may contain patient-specific treatment and prescription data, and thus access to such databases may be severely limited. 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. The Web portal 150 enables the patient and clinics 152 a-152 h that treat the patient to access Web sites that are publicly available to users of the medical fluid delivery machine 90. The business intelligence portal 160 collects data from the system hub 120 and provides the data to marketing 162, research and development 164, and quality/medication alerting 166.

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

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

In one embodiment, the home therapeutic device 90 uses, for example, Linux^TMThe operating system writes a log file. The log file records data relating to the home treatment device 90, including peripheral device data. The log file may include any one or more of extensible markup language ("XML"), comma separated values ("CSV"), or text files. The log file is placed in a file server box of the software of the home treatment apparatus 90. It is also contemplated that data not sent to machine 90 may be stored at a peripheral device, such as water treatment device 60. Such data may be obtained in other ways via a wired or wireless connection to a peripheral device, or may be downloaded via other data connections or storage media. For example, the service person may be, for example, via The additional data is accessed via a laptop computer connected to the water treatment device 60 or the wireless weight scale 106 by an ethernet connection. Alternatively, the additional data may be retrieved remotely from the peripheral device using the home therapy device 90 for data transfer communication between the peripheral device and an authorized client of the medical fluid data transfer system.

In one embodiment, the home therapy device 90 uses a connectivity service to transmit data between the modem 102 and the system hub 120, for example, via the internet. Here, a dedicated line may be provided in each patient's home for connecting the home therapy apparatus 90 to the connection server 118 via the modem 102. In one embodiment, the home therapy device 90 uses a separate, e.g., 3G, 4G or 5G, modem 102 to access the Internet. Modem 102 may use, for example, Vodafone^TMAn internet service provider ("ISP"). In one embodiment, a connection broker 114 developed by a connection service provider (e.g., the provider of the connection server 118) is installed on the home therapy device 90 and runs on the ACPU 50 of the machine. One suitable connection service is made by Axeda^TMThe service provides a secure management connection 116 between the medical device and a connection server 118.

The connection broker 114 allows the therapeutic home appliance 90 to connect to the connection server 118 and to transfer data to and from the connection server 118. The connection service operating via the proxy 114 and the server 118 ensures that the connection to the machine 90 is secure, that the data correctly passes through the firewall of the machine 90, checks for the presence of data or a system crash, and ensures that the connection server 118 is communicating with the correct home therapy appliance 90.

In one embodiment, the home therapy appliance 90 may only connect to the connection server 118 when the connection broker 114 is turned on or activated. During treatment and post-treatment sterilization, while the machine 90 and its peripherals are operating properly, in one embodiment, the connection broker 114 is closed, preventing the home treatment apparatus 90 from communicating with any entity and from sending or receiving data during treatment and sterilization or while the machine 90 is running or operating. In one embodiment, the ACPU 50 opens the connection broker 114 when the home therapy device 90 is idle, e.g., after completion of treatment and disinfection. In an embodiment, the connection broker 114 is turned off during treatment and possibly during pre-processing. After treatment, the connection broker 114 retrieves the log file from the home treatment apparatus 90 and transmits the data to the connection server 118 using the connection service. In one embodiment, the connection service routes the data packet to its appropriate destination, but does not modify, access, or encrypt the data.

In the medical fluid data transmission system 10 system of fig. 1, a connection service via the connection server 118 may transmit data to various locations via a system hub 120, such as a service portal 130, clinics or hospitals 126a through 126n, and a Web portal 150. The connection server 118 allows the service personnel 132a through 132h and/or clinicians to track and retrieve various assets over the network, such as the appropriate home therapy device 90 and 3G, 4G or 5G modem 102, and their associated information, including machine or modem serial numbers. The connection server 118 may also be used to receive firmware upgrades approved by the supervisor of the attendant 134 and obtained remotely via the service portal 130 and provide them to authorized home treatment appliances 90 and associated peripheral devices, such as the water treatment device 60.

A. Example medical fluid delivery machine

Referring now to fig. 2, an example of an HD flow schematic for a medical fluid delivery machine 90 is shown. Because the HD system of fig. 2 is relatively complex, fig. 2 and the discussion thereof also provide support for any of the renal failure treatment modalities discussed above, as well as IV, drug delivery, or nutrient delivery machines. Generally, the medical fluid delivery machine 90 is shown in simplified form as having a dialysate or process fluid delivery circuit. The blood circuit is also simplified, but not to the extent that the dialysate circuit is simplified. It will be appreciated that the circuitry has been simplified to facilitate the description of the present disclosure, and that additional structures and functionality, such as found in the publications incorporated by reference above, will be had if the system were implemented.

The medical fluid delivery machine 90 of fig. 2 includes a blood circuit 20. The blood circuit 20 draws blood from the patient 12 and returns the blood to the patient 12. Blood is drawn from the patient 12 via arterial line 14 and returned to the patient via venous line 16. The arterial line 14 includes an arterial line connector 14a connected to an arterial needle 14b, which arterial needle 14b is connected to the patient 12 for blood withdrawal. The intravenous line 16 includes an intravenous line connector 16a connected to an intravenous needle 16b, the intravenous needle 16b being in return blood communication with the patient. The arterial and venous lines 14 and 16 also include line clamps 18a and 18v, which may be spring-loaded fail-safe mechanical compression clamps. In one embodiment, the line clamps 18a and 18v automatically close in the event of an emergency.

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

In the illustrated embodiment, a blood pump 30 is located in the arterial line 14. In the illustrated embodiment, the blood pump 30 includes a first pump compartment 30a and a second pump compartment 30 b. The pump chamber 30a operates with an inlet valve 32i and an outlet valve 32 o. The pump compartment 30b operates with an inlet valve 34i and an outlet valve 34 o. In one embodiment, the blood pump pods 30a and 30b are each a blood receptacle that includes a rigid housing, such as a sphere, with a flexible diaphragm within the housing, thereby forming a diaphragm pump. One side of each diaphragm receives blood, while the other side of each diaphragm is operated by negative and positive air pressure. The blood pump 30 may alternatively be a peristaltic pump operating with the arterial line 14 or a plurality of peristaltic pumps operating with the arterial line 14 and the venous line 16.

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

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

For the hemodialysis version of the medical fluid delivery machine 90 of fig. 2, dialysate is pumped along the exterior of the membrane of the hemofilter 40, while blood is pumped through the interior of the hemofilter membrane. The dialysate is first prepared by purifying water via a water purification unit 60. One suitable water purification unit is set forth in U.S. patent publication No.2011/0197971 entitled "water purification system and method" filed on 25/4/2011, which is incorporated herein by reference in its entirety. In one embodiment, the water purification unit includes a filter and other structures to purify tap water (e.g., to remove pathogens and ions, such as chlorine) such that, in one embodiment, the water has endotoxin units below 0.03 milliliters ("EU/ml") and colony forming units below 0.1ml ("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 dialysate circuit 70.

The dialysate circuit 70 is again highly simplified in fig. 2 to simplify the illustration. Indeed, the dialysate circuit 70 can include all relevant structures and functions set forth in the publications incorporated by reference above. Certain features of the dialysate circuit 70 are shown in fig. 2. In the illustrated embodiment, the dialysate circuit 70 includes a hemofilter dialysate pump 64. In one embodiment, the pump 64 is configured the same as the blood pump 30. Like pump 30, pump 64 includes a pair of pump chambers 66, each having an inlet valve 68i and an outlet valve 68o, which may also be spherical. Like the blood pump 30, the two pump compartments are operated alternately, so that one pump compartment is filled with HD dialysate and the other pump compartment is drained of HD dialysate.

The pump 64 is a hemofilter dialysate pump. There is another dual chamber pump chamber 96 which operates with valves 98i and 98o located in the drain line 82 to push spent dialysate out. There is a third tank pump (not shown) for pumping pump purified water through the bicarbonate box 72. There is a fourth tank pump (not shown) for pumping acid from the acid container 74 into the mixing line 62. The third and fourth pumps, i.e., the concentrate pumps, may be single compartment pumps, as in one embodiment, continuous pumping in the mixing line 62 is not important due to the presence of a buffer dialysate tank (not shown) between the mixing line 62 and the hemofilter dialysate pump 64.

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

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

In one embodiment, purified water from water purification unit 60 is pumped along mixing line 62 through bicarbonate cartridge 72. Acid from the 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 dialysate solution. The pump and temperature compensated conductivity sensor for proper mixing of the purified water with bicarbonate and acid are not shown, but are disclosed in detail in the publications incorporated by reference above.

Fig. 2 also shows that the dialysate is pumped along the fresh dialysate line 76 through a heater 78 and an ultrafilter 80 before reaching the hemofilter 40, after which the used dialysate is pumped out via an exhaust line 82. The heater 78 heats the dialysate to body temperature or about 37 ℃. The ultrafilter 80 further purifies and purifies the dialysate prior to reaching the hemofilter 40, filtering out foreign matter and/or contaminants introduced from the dialysate, for example, via the bicarbonate cartridge 72 or the acid container 74.

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

In the illustrated embodiment, the medical fluid delivery machine 90 is an in-line, straight-through system that pumps dialysate through a hemofilter at a time, and then pumps the spent dialysate for discharge. After each treatment, both the blood circuit 20 and the dialysate circuit 70 can be hot water sterilized so that the blood circuit 20 and the dialysate circuit 70 can be reused. In one embodiment, the blood circuit 20 including the blood filter 40 is hot water sterilized and reused for about one month each day, while the dialysate circuit 70 is hot water sterilized and reused for about six months.

In an alternative embodiment, for example for CRRT, multiple bags of sterile dialysate or infusate are combined together and used one after the other. In this case, the emptied supply bag may be used as a drain bag or a waste bag.

The medical fluid delivery machine 90 includes a housing as shown in phantom in fig. 2. The housing of the machine 90 varies depending on the type of treatment, whether the treatment is a central or home treatment, and whether the dialysate/infusate supply is intermittent (e.g., bagged) or on-line.

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

In fig. 2 and 3, any of 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, each pump and valve has a fluid side and an air side separated by a flexible membrane. Negative air pressure can be applied to the air side of the membrane to draw fluid into the pump chamber or open the valve (or the pump or valve can be opened by venting positive closed air pressure to atmosphere and allowing the fluid pressure to open). Positive air pressure is applied to the air side of the membrane to expel fluid from the pump chamber or close the valve.

B. Exemplary medical fluid delivery System connective embodiments

Referring now to fig. 4, a system 110a of the present disclosure is shown. System 110a in the illustrated embodiment operates with system 10 described above, including connection server 118, system hub 120, service portal 130, enterprise resource planning system 140, Web portal 150, and business intelligence portal 160, which are illustrated in FIG. 4 as part of a cloud environment. Connection server 118, system hub 120, service portal 130, enterprise resource planning system 140, Web portal 150, and business intelligence portal 160 may each be part of a cloud environment or located on one or more dedicated servers.

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

As described above, the medical fluid delivery machines 90a and 90b are connected to the connection server 118 via the secure management connection 116. To this end, machines 90a and 90b are connected to the internet 52, for example, via the modem 102 described above. In one embodiment, the system hub 120 stores middleware software that is accessible by the mobile communication devices 200a and 200b (collectively referred to herein as devices 200 or generally individually as devices 200). Mobile communication devices 200a and 200b may be examples Such as in Android^TM、iOS^TM、Windows Phone^TM、BlackBerry^TM、Sailfish OS^TM、Tizen^TMOr Ubuntu Touch^TMA smart phone running on an operating system. 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 shown 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 app is updated whenever the state of the respective machine 90a or 90b changes. For example, the medical fluid delivery machine 90a may have just completed its automated self-test routine and is now ready to run a sterilization process. Machine 90a may generate a code identifying the status and send it to middleware software stored on system hub 120. The middleware software then converts the code into a message, such as "self-test complete, ready to disinfect," using, for example, a look-up table, and causes the application downloaded to the patient 12a or the clinician 112a mobile communication device 200a to display the message. The application may be programmed to provide, along with the message, a visual identifier, such as an icon associated with the particular state that machine 90a is in. The application may also provide any one or more of an audio alert (such as a "ding" sound) and/or a tactile alert (such as a vibration) that may prompt the patient 12a or clinician 112a to view the application and learn of a change in the state of the machine 90.

In another example, the medical fluid delivery machine 90b may have been pre-programmed to begin treatment at 3:00 PM. The medical fluid delivery machine 90b may require three hours for self-testing and sterilization. Thus, patient l2a or clinician 112a needs to be at machine 90b before noon to begin pre-treatment. In one embodiment, patient l2a or clinician 112a makes a setting on machine 90b regarding how long (e.g., 2 hours) before the three hour preparation time patient 12a or clinician 112a should be notified or reminded. Thus, in this example, machine 90b may generate code at 10:00 am and send the code to the middleware software stored on system hub 120. The middleware software then transcodes, for example using a look-up table, into a message, such as "treatment preparation needs to begin within two hours" and causes the application downloaded to patient l2b or to the mobile communication device 200b of clinician 112b to display the message. The application may again be programmed to provide a visual identifier with the message, such as a countdown timer that counts down from one hundred twenty minutes to a zero timeout. The application may also provide any one or more of an audio alert (such as a "ding" sound) and/or a tactile alert (such as a vibration) prompting the patient l2b or clinician 112b to view the application and learn of the treatment preparation notification. The application may also be programmed to repeat the "ding" sound and/or tactile feedback process at pre-programmed intervals (e.g., at one hour and thirty minutes) during the countdown period.

In addition to or instead of providing the application on the user's communication device 200b, it is also contemplated that middleware software at the system hub 120 will convert code from the machine 90b into a message deposited on the device 200's native task tracking function, such as its calendar application. For example, most smartphone devices 200 are provided with a calendar that divides each day into time periods, such as hours. Here, messages converted by the middleware software of the system hub 120 may be programmed to access the calendar of the authorized communication device 200b and fill in the appropriate time period for the appropriate date with the appropriate information. In the example above, for the appropriate date, the native calendar software application will fill in a message in its 10:00:00 PM time slot, such as "therapy preparation needs to begin within two hours". An audio and/or tactile feedback signal may be provided to inform the patient 12 or clinician 112 of the calendar entry.

It should be appreciated that the machines 90a and 90b, middleware software at the central server 120, and 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, it is also possible to inform the patient 12a, 12b and/or clinician 112a, 112b at the end of the sterilization by an accompanying countdown timer that treatment needs to be initiated within the countdown time to avoid having to re-sterilize the machine 90a, 90 b.

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

In one embodiment, the system hub 120 stores middleware software that is accessible by the mobile communication devices 200 (shown as a single device for convenience, but multiple devices 200 may be similarly connected to the system 110 b). The mobile communication device 200 in fig. 5 includes all of the structures, functions, and alternatives disclosed for the devices 200a and 200b shown in fig. 4, including connection to the internet 52. In fig. 5, the mobile communication device 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 application may operate exactly as described above in connection with fig. 4, including middleware software that converts encoded messages from the machine 90 into a format that can be rendered on the application. Alternatively or additionally, middleware software stored on the system hub 120 can transcode from the machine 90 into a message deposited on a native task tracking function of the mobile communication device 200 (such as its calendar application) in any of the manners described in fig. 4.

Further alternatively or additionally, the system 110b includes a cellular network 210, the cellular network 210 connecting between middleware software stored, for example, at the system hub 120 and the mobile communication device 200. Cellular network 210 may include a network of cellular telephone towers operating using radio waves and/or employ satellites. The communication protocol suitable for use with the cellular network 210 of system 110b may be a long range protocol, such as (i) a "worldwide interoperability for microwave access" ("WiMAX") protocol; and (ii) the global system for mobile communications (GSM) protocol, which is a widely used long-range wireless protocol, that supports data communications with many cellular telephones in the world. Network 210 may alternatively or additionally employ a mid-range protocol, such as a wireless local area network ("WLAN"), which may be part of an 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.11 n. Other suitable cellular technologies may include CDMA, AMPS (analog), general packet radio service ("GPRS"), cdmaOne, CDMA2000, evolution-data optimized ("EV-DO"), enhanced data rates for GSM evolution ("EDGE"), universal mobile telecommunications system ("UMTS"), digital enhanced cordless telecommunications ("DECT"), digital AMPS ("IS-136/TDMA"), and integrated digital enhanced networks ("iDEN").

The mobile communication device 200 communicates with the cellular network 210 via any means known to those skilled in the art, for example, via a short message service ("SMS") or multimedia message service ("MMS") protocol. The middleware software at the system hub 120 may communicate with the cellular network 210 in a variety of ways. In one example, the phone number and carrier of a user 12, 112 (any or all of the patient 12, the patient at a home care partner, the patient's clinician 112) is associated with a particular machine 90, e.g., via a look-up table at middleware software. When a message/code is received by the middleware from a particular machine 90, the middleware software may be programmed to send a [ user telephone number ]]@ [ operators]Net sends e-mail. For example, if the patient 001's phone number is (555)555-5555, and the operator of the patient 001 is AT&T^TMWhen the patient 001 is in the machine 90 directionWhen the middleware software of hub 120 sends a message, upon receipt of the message, middleware software 120 is programmed to relay the email to [email protected] att. It is understood by those skilled in the art that there are a number of web sites devoted to informing how text messages are sent by email, outlining the details required by the different operators.

The middleware software stores each of the phone numbers of each mobile communication device 200 and matches each phone number with the machine 90. As described above, when an event code is sent from the machine 90 to the middleware software, the middleware software locates the telephone number of the mobile communications device 200 associated with the machine, translates the code into the appropriate message, for example using a look-up table as described above, and sends the translated message to the called out telephone number. It is contemplated that multiple communication devices 200 may be associated with the same medical fluid delivery machine 90. For example, in any of clinics 126 a-126 n, the telephone numbers of multiple doctors, nurses, and/or clinicians may be associated with the same machine 90. In a home environment, the telephone numbers of the patient 12 and its clinician and/or caregiver assistants may be associated with the same machine 90.

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

The cellular message may convey information about any of the same events used to populate the software app and calendar update modes of the mobile communication device 200 with information, as described above. For example, the medical fluid delivery machine 90 may have just completed its automatic self-test procedure and be ready to run a sterilization process. Machine 90a may generate a code identifying the status and send it to middleware software stored on system hub 120. The middleware software then converts the code into a message, such as "self-test complete, ready to disinfect," using, for example, a look-up table, and causes, for example, the cellular output routine described above to send a text message to the mobile communication device 200 of the patient 12 or clinician 112 to display the message. In an alternative embodiment, no code is 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 via, for example, the cellular output routine discussed above. As is well known, receipt of a text message on the communication device 200 may be accompanied by audio, for example, a "ding" 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 have been pre-programmed to operate at 3 pm: 00 begin treatment. The medical fluid delivery machine 90 may again take three hours to self-test and sterilize. Thus, the patient 12 or clinician 112 needs to be at the machine 90 before noon to begin pre-treatment. In an embodiment, the patient 12 or clinician 112 makes a setting on the machine 90 regarding how long (e.g., 2 hours) before the three hour preparation time the patient 12 or clinician 112 should be notified or reminded. Here, the machine 90 generates code at 10:00 AM and sends the code to the middleware software stored on the system hub 120. The middleware software then transcodes the code into a message, such as "treatment preparation needs to begin within two hours," for example, using a look-up table, and causes the cellular output routine, for example, described above, to send a text message to the mobile communication device 20 of patient l2 or clinician 112 to display the message, for example, along with an audio alert (such as a "ding" sound) and/or a tactile alert (such as a vibration), prompting patient l2 or clinician 112 to view the notification.

It should be appreciated that the middleware software at the machine 90, central server 120, and communication device 200 may be programmed and operated as described above to alternatively or additionally provide any desired messages to the patient 12 and/or clinician 112 using the cellular network 210. For example, at the end of sterilization, the patient 12 and/or clinician 112 may also be notified that treatment needs to be initiated within a countdown period of time to avoid having to re-sterilize the machine 90. It should also be appreciated that the updating of the native task tracking feature, such as the calendar application of the communication device 200, may be accomplished through an internet connection or via the cellular network 210 shown in fig. 5.

Referring now to fig. 6, a system 110c of the present disclosure is shown. The system 110c in the illustrated embodiment operates with the system 10 described above, including 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 shown in FIG. 6, shown in FIG. 6 as part of a cloud environment, but may alternatively be located on one or more dedicated servers. Other components of system 10 not shown in fig. 6 may also be part of system 110 a. For ease of description, a single medical fluid delivery machine 90 is shown, however, multiple medical fluid delivery machines 90 may be similarly connected to the system 110 b. The medical fluid delivery machine 90 may be located in the home of the patient 12 (not shown) or in the clinics 126 a-126 n of the clinician 112. In the illustrated embodiment, the medical fluid delivery machine 90 is again connected to the connection server 118 using, for example, the modem 102 via the secure management connection 116 and the internet 52 connection. In fig. 6, the connection server 118 and the secure management connection 116 are used for two-way communication.

In one embodiment, the system hub 120 stores middleware software that is accessible by the mobile communication devices 200 (shown as a single device for convenience, but multiple devices 200 may be similarly connected to the system 110 b). The mobile communication device 200 in fig. 6 includes all of the structures, functions, and alternatives disclosed for the devices 200a and 200b shown in fig. 4, including connection to the internet 52. In fig. 6, the mobile communication device 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 application may operate just as described above in connection with fig. 4, including middleware software converting the encoded message from the machine 90 into a format that can be rendered on the application. Alternatively or additionally, middleware software stored on the system hub 120 may be capable of transcoding from the machine 90 into a message deposited 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 discussed above in connection with fig. 5 (shown as an alternative via the dashed lead in fig. 6).

Fig. 6 illustrates that the communication between the medical fluid delivery machine 90 and the mobile communication device 210 may be bi-directional. Communication between the mobile communication device 210 and the middleware software at the server computer 120 may occur via the internet 52 and/or the cellular network 210. As described in detail above, communication between the middleware software at the server computer 120 may occur via the connection server 118 via the secure management connection 116.

As described above, the home therapy device 90 is connected to the connection server 118 via its on-board connection agent 114. in one embodiment, the on-board connection agent 114 is turned off during therapy, for example, while the machine 90 and its peripheral devices are running (the on-board connection agent 114 may or may not be turned off during post-therapy disinfection). This prevents the home therapy apparatus 90 from communicating with any entity and transmitting or receiving data during treatment and disinfection or when the machine 90 is active or operational. It is contemplated that communications via systems 110 a-110 c are secured in the same manner. For example, assume that a particular machine 90 is set up via middleware software to communicate with both the patient 12 and the clinician 112. Here, if the patient is being treated by the machine 90, it may be contemplated to disconnect the connection broker 114 so that the clinician 112 cannot receive notifications from the machine 90 or send commands to the machine 90 at this time. In an alternative embodiment, the clinician 112 may be able to receive notifications from the machine 90 during treatment.

The determination of when to disconnect the agent 114 (no communication) may depend on what the machine claim systems 110 a-110 c desire to communicate with the mobile communication device 200, or how many machine claim systems 110 a-110 c desire to communicate with the mobile communication device 200. For example, assuming that it is only desirable to notify the patient 12 or clinician 112 two hours before treatment preparation, the patient 12 or clinician 112 needs to return to the machine 90 to begin treatment preparation. Here, the connection broker 114 may be closed once the patient 12 or clinician 112 begins a first therapy preparation step, such as running a self-test routine.

In another example, it may be desirable for machine 90 to automatically run a self-test routine at some preset time prior to beginning treatment. The machine 90 notifies the patient 12 or clinician 112 when sterilization is initiated. Here, once the patient 12 or clinician 112 begins machine sterilization, the connection broker 114 may be disconnected. In another example, it may be desirable for the machine 90 to notify the patient 12 when sterilization is complete so that the patient begins treatment within a certain time from the end of sterilization so that repeated sterilization is not required. Here, the connection broker 114 may be disconnected once the patient 12 or clinician 112 begins treatment, for example, when the patient is still connected to a treatment line (e.g., arterial line 14 or venous line 16) in the initial stage of the procedure.

The system 110c allows the patient 12 or clinician 112 to remotely initiate any of the above-described actions (as well as other actions not explicitly described herein). The patient 12 or clinician 112 may, for example, select an icon of an application displayed on the mobile communication device 200 to begin, for example, a self-test routine or a disinfection process. The selection of the icon is communicated to the middleware software via the internet 52. The middleware software may then translate the icon selection, for example via a look-up table, into an action code that is sent to the machine 90 with the connection broker 114 in the open state via the connection server 118 and the secure management connection 116, allowing the action code for the selected action to be sent to the ACPU 50 of the machine, and the ACPU 50 begins to perform the selected action.

In an alternative embodiment, the patient 12 or clinician 112 may enter a known code, for example, in a text message, to select a particular action to be performed at the machine 90, such as a self-test routine or a disinfection process. The code may be an suggestive code, such as "self-test" or "disinfection". The text message is sent via the cellular network 210 to the middleware software at the system hub 120. The middleware software translates the text code into an action code for the selected action, e.g., via a look-up table. Alternatively, the code entered by the patient 12 or clinician 112 may be an action code, so that no translation is required. In either case, the action code is sent to the machine 90 with the connection broker 114 in the open state via the connection server 118 and the secure management connection 116, allowing the action code for the selected action to be sent to the machine's ACPU 50 to begin performing the selected action.

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

In step 3, the customized application downloaded to the patient's mobile communication device 200 will initiate the start of the automated self-test procedure, for example, for two hours, via an audio, visual, and/or tactile alert and associated message, alerting the patient 12 that the patient 12 is ready for the patient's 12 machine 90. In step 4, the patient 12 uses the customized application on the mobile communication device 200 to confirm that the machine 90 should initiate its automated self-test routine.

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

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

With respect to the systems 110a to 110c, it is envisaged that the application on the mobile communications device 200 is programmed so that it can be configured by the user to select what kind of notification the user wishes to receive on his device 200, for example via the application itself, via a text message and/or via a calendar notification. In one embodiment, the system hub 120 may send all notification types, wherein the mobile communication device 200 ignores communication types that the user has disabled. In another embodiment, the system hub 120 stores the user's preferences and transmits information only with the selected notification type.

C. Clinician device/server embodiments

Referring now to fig. 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 shown on screens 232-236. As described above, the mobile communication device 200 may be the mobile communication device of the patient 12, or may be the mobile communication device of the doctor/nurse/clinician 112. The screens 232 to 236 of fig. 7 to 9 show that the application 230 may be used in a clinic or hospital 126a to 126n, where a nurse is responsible for a plurality of machines 90a to 90n, for example. Machines 90 a-90 n may again be hemodialysis machines, peritoneal dialysis machines, CRRT machines, drug and/or nutrient delivery machines, and combinations thereof.

Screen 232 shows that application 230 may monitor and control (if desired) multiple machines 90. In the illustrated embodiment, machines 90a through 90n are represented by dedicated icons 190a through 190n, respectively, displayed on a screen 232 of application 230. In the illustrated embodiment, the sequence of icons 190 a-190 n on screens 232-236 is the same as the sequence of machines 90 a-90 n in clinics 126 a-126 c to help orient the doctor/nurse/clinician 112.

It is contemplated that the application 230 operates with the system hub 120 as has been discussed herein, wherein the system hub 120 is remote from the clinic or hospital 126 a-126 n and is maintained, for example, by the manufacturer of one or more of the machines 90 a-90 n. For example, the application 230 may be initially developed at the product development 128 shown in FIG. 1. The application 230 may then be sent from the product development 128 to the system hub 120 via the service portal 130, as shown in fig. 1 and 7. Any nurse, clinician, or doctor 112 authorized to download the application 230 may download from the system hub 120. Thereafter, the system hub 120 maintains middleware software to operate with the application 230 in the systems 110 a-110 c in the manner described above.

In an alternative embodiment, clinics 126a through 126n may maintain their own local area networks, each operating with local system hub 220. Application 230 may again be developed by product development 128 (FIG. 1) and transmitted via service portal 130 to local system hub 220 of clinics 126a through 126n operating with the overall system 10. Each nurse, clinician or doctor 112 authorized to download the application 230 downloads from the local system hub 220. Thereafter, the local system hub 220 maintains middleware software for operation with the application 230 in the manner described above for the system hub 120 in the systems 110 a-110 c. In another alternative embodiment, the application 230 may be developed by the clinics 126 a-126 n and stored on their local system hub 220.

Middleware software of the system hub 120 or the local system hub 220 updates the status of each machine 90a to 90 n. At any time, the nurse, clinician or doctor 112 may select icons 190 a-190 n to view the current status of each machine 90 a-90 n, such as "rest," "self-test," "disinfect," or "treat patient," as shown in screen 234 of fig. 8. Other status flags are contemplated and may vary for different types of machines. The nurse, clinician or physician 112 may then select any of "rest," "self-test," "disinfect," or "treat patient" to return to the home icons 190 a-190 n as shown in fig. 9.

As described above, it is contemplated that the connection broker 114 of each machine 90 is shut down while the machine is operating, particularly when the patient 12 is connected to the machine. However, it is also contemplated to allow the connection broker 114 of each machine 90 a-90 n of a clinic 126 a-126 n to remain on until disinfection is complete so that middleware software at the system hub 120 or local system hub 220 may receive a status change from each machine 90 a-90 n to "treat the patient". In addition, because each machine 90 a-90 n knows its planned treatment duration, the machine may also send the planned duration to middleware software which then sends the duration in the form of a countdown timer along with the status change of the "treating patient". Here, then, when the nurse, clinician or doctor 112 selects "treat patient" in FIG. 8, they can see a countdown timer indicating the remaining treatment time, as shown in FIG. 9.

It is contemplated that for a countdown timer, the connection broker 114 allows the machines 90 a-90 n to send remaining time data to the system hub 120 so that the application 230 can display the actual remaining time for each machine 90 undergoing timed processing. Application 230 takes into account alarms or other delays that may be experienced by machine 90. During an alarm condition, the respective icons 190 a-190 f may display a message such as "alarm" or "safe mode". The nurse, clinician or physician 112 may then select the countdown time in fig. 9 to return to the home icons 190c, 190d and 190h shown in fig. 7.

The nurse, clinician, or doctor 112 may also toggle the alarm on/off icon 238 to allow or disallow the change in status of the machines 90 a-90 n to be alerted visually, audibly, and/or tactilely. If the alert on/off icon 238 is switched "on," the application 230 of the mobile communication device 200 may provide a visual, audible, and/or tactile alert each time the machine state changes, such as: (i) initiation of self-test, (ii) completion of self-test, (iii) initiation of sterilization, (iv) completion of sterilization, (v) initiation of treatment, (vi) completion of treatment. In an embodiment, the code of (i) through (v) is sent via machines 90a through 90n through secure management connection 116, connection server 118, and system hub 120 or local system hub 220 to be translated by middleware software and forwarded to application 230, which application 230 updates the appropriate icon 190. In various embodiments, "(vi) treatment complete" may be either (a) sent via the machines 90 a-90 n with the connection broker 114 active, or (b) inferred when the countdown timer for the appropriate icon 190 a-190 n expires and while the connection broker 114 is still closed.

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

Screens 232-236 show action buttons 240a and 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 in any form (e.g., hemodialysis, peritoneal dialysis, CRRT, drug and/or nutrient delivery). In the illustrated embodiment, action button 240a is used to initiate a self-test of machine 90, while action button 240b is used to initiate a sterilization sequence of machine 90.

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

In the illustrated embodiment, when the sanitize button 240b is selected, any machine 90 a-90 n that is capable of performing sanitization at that time has its corresponding icon 190 a-190 n highlighted. The nurse, clinician, or doctor 112 selects any icon 190 that the nurse, clinician, or doctor 112 wishes to perform disinfection. The selected icon 190 may again become the "ok" button which the nurse, clinician or doctor 112 must press again to cause the selected machine 90 to perform its sterilization. The application 230 of the mobile communication device 200 then sends the corresponding disinfection code to the middleware software at the system hub 120 or the local system hub 220, which if necessary converts the disinfection code into a disinfection initialization command, which is sent via the connection server 118 over the secure management connection 116 to the connection broker 114 of the selected machine 90, which transmits the command to the machine's ACPU 50, which in turn initializes the disinfection.

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

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

In one embodiment, when mobile communication device 200 transmits data to system hub 120 or local system hub 220 for transmission to machine 90, the data is provided with an identifier of mobile communication device 200 that identifies the mobile communication device 200 from which the data was transmitted. As described above, the system hub 120 or the local system hub 220 may or may not translate data from the mobile communication device 200, but in either case, maintains a mobile communication device 200 identifier for the connection server 118. Connection server 118 knows which machine 90 is to receive, for example, the converted data for each mobile communication device 200 and send, for example, the converted data to each associated communication device 200. Once transferred to machine 90, connection server 118 may strip the identifier of mobile communication device 200 from the data as it is no longer needed.

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

Example of patient participation

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

The example medical fluid data transmission system 1000 includes a personal mobile communication device 200a operated by a patient, for example. The medical fluid data transmission system 1000 also includes a blood pressure monitor 104, a weight scale 106, and a home care device 90, which are similar to the various devices discussed above in connection with fig. 1-9. The personal mobile communication device 200a, the home therapy apparatus 90, the blood pressure monitor 104 and the weight scale 106 may be located, for example, in the patient's home, a self-service clinic and/or a service medical clinic.

The home therapy device 90 may include any type of hemodialysis machine, peritoneal dialysis machine, CRRT machine, drug and/or nutrient delivery machine, and combinations thereof. The home therapy device 90 can provide, for example, continuous cycle peritoneal dialysis ("CCPD"), tidal flow automated peritoneal dialysis ("APD"), and continuous flow peritoneal dialysis ("CFPD"). The home therapy device 90 may automatically perform the drainage, filling and dwell periods, typically while the patient sleeps.

The peritoneal dialysis dialysate can include a solution or mixture that contains 0.5% to 10% glucose (or more generally glucose), preferably 1.5% to 4.25%. Peritoneal dialysis dialysate can include, for example, that sold by the assignee of the present disclosure Andand (4) dialyzing liquid. The dialysate 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 spent dialysate, to reinject therapeutic agents (e.g., ions and/or glucose) into the treated fluid, and then to reuse the fluid to continue dialysis in the patient. One commonly used adsorbent is made of zirconium phosphate, which is used to remove ammonia produced by the hydrolysis of urea. Generally, a large amount of adsorbent is required to remove ammonia generated during dialysis treatment.

The example weight scale 106 includes any device configured to measure the mass of a patient or a therapeutic component. For example, the weight scale 106 may measure the patient's weight before, during, and/or after a renal failure treatment. Additionally or alternatively, the weight scale 106 may measure a replenishment or drainage bag used to track renal failure therapy. In particular, the weight scale 106 may be used to measure the amount of UF removed or the amount of fluid provided to the patient. The weight scale 106 may display a numerical value indicative of body weight. Alternatively, the weight scale 106 may display a physical scale or dial aligned with the indicia to indicate the measured weight. In some embodiments, the weight scale 106 may store the weight values before, during, and/or after treatment in a separate window, such that patient input is required to view all values when recording medical information.

The example blood pressure monitor 104 includes any device configured to measure the blood pressure and/or pulse of a patient. For example, the blood pressure monitor 104 may measure the blood pressure of the patient before, during, and/or after a renal failure 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 the blood pressure values before, during, and/or after treatment in a separate window, such that patient input is required to view all values when recording medical information. The blood pressure monitor 104 may be integrated with the home therapy device 90. In another embodiment, the blood pressure monitor 104 may include a wearable sensor, such as a smart watch or fitness tracking device.

In addition to obtaining medical information (e.g., medical device data) from the medical devices 90, 104, and 106, the example personal mobile communication device 200a may also obtain medical information from the patient and/or the treatment consumable 1006. Fig. 10 shows an example of a consumable 1006 that includes, 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 drug container, and/or a water purification container). The consumable 1006 may also include a sorbent cartridge or any other disposable or material supply for medical treatment. The consumable may include an identifier 1008 configured to provide medical information in the form of consumption information or consumption data. For example, identifier 1008 may include information identifying the type of consumable, a serial number, and/or attributes of the consumable. In some cases, the consumable 1006 may also include a label containing medical information (such as chemical composition properties). The patient or clinician uses the personal mobile communication device 200a to record an image of the identifier 1008, an image of the tag on the consumable 1006, and/or an image of the consumable 1006 itself to record the material used during the treatment.

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

The blood pressure monitor 104 and the weight scale 106 are collectively referred to as medical devices. It should be appreciated that the medical fluid data transmission system 1000 may include additional medical devices, such as infusion pumps (e.g., syringe pumps, linear peristaltic pumps, high volume pumps ("LVPs"), ambulatory pumps, multi-channel pumps), oxygen sensors, respiratory monitors, blood glucose meters, blood pressure monitors, electrocardiogram ("ECG") monitors, weight scales, and/or heart rate monitors. In other examples, the medical fluid data transmission system 1000 may include fewer medical devices and/or integrated medical devices (e.g., the blood pressure monitor 104 integrated with the home therapy device 90).

In some embodiments, the personal mobile communication device 200a is configured to record, display and/or fill in patient medical records with medical information or data. As disclosed herein, medical information or data includes medical device data and patient data, which may refer to data or information created, generated, or otherwise related to a medical device, patient, and/or consumable used by a medical device. For example, medical information includes prescription or programming information used by the medical device to manage therapy. The medical information also includes sensed data such as fluid pressure, flow rate, conductivity, concentration, temperature, and patient data. As provided herein, patient data (e.g., vital sign data) includes sensed patient physiological information, such as patient blood pressure, weight, heart rate, and the like. The medical information may also include subjective information, such as information about the patient's feelings (e.g., tiredness, fatigue, happiness, excitement, etc.). The medical information may be displayed on a screen of the medical device, provided by a physical dial or display of the medical device, or printed on an attached label or medical device. Thus, the 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 on a patient or a therapeutic consumable. In particular, the medical information may include information conveyed by an identifier provided on the patient wristband for identifying the patient of the patient. The medical information also includes information about the consumable that can identify the type of consumable, the model of the consumable, and/or the nature of the consumable, such as the glucose level in a bag supply of renal failure treatment solution.

The treatment data or treatment information refers to data generated and/or transmitted by the home treatment apparatus 90 of fig. 1-10. The treatment information may include the amount of fluid injected, the amount of UF removed from the patient, and/or the treatment time. The treatment information may also include alarm, reminder, and/or diagnostic information generated by the home therapy apparatus 90. Typically, the treatment information is transmitted from the home treatment apparatus 90 to the clinician server 200 b. In some embodiments, the treatment information may be recorded in the personal mobile communication device 200 a. In these embodiments, the therapy information may be referred to 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 encode, for example, a specified device number, serial number, hardware number, model number, and/or device type for each medical device 90, 104, and 106. For example, the identifier 1012b of the home treatment apparatus 90 may store a designated device number. The personal mobile communications device 200a reads the identifier 1012b to determine, for example, the medical device type for subsequent analysis and identification of medical information in images recorded from the screen of the machine 90. In some embodiments, the identifier 1012 may more generally indicate the model or type of medical device. For example, the identifier 1012c may indicate that the device 106 is a weight scale and/or indicate a model of a weight scale.

Identifier 1012 may include machine-readable indicia, such as a barcode or quick response ("QR") code. The identifier 1012 may also include human-readable text, such as a serial number, asset number, or hardware number. In some embodiments, the identifier 1012 may be printed onto 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 apparatus 90. Additionally or alternatively, the identifiers 1012 may be displayed on the screens of some of all of the medical devices 90, 104, and 106. For example, the clinician may select the control interface to cause the home treatment apparatus 90 to display a window with the identifier 1012b on the screen. In other embodiments, the identifier 1012 may be included within a radio frequency ("RF") microchip, such as an RFID chip or an NFC chip.

The example medical devices 90, 104, and 106 may also include one or more control interfaces for providing control instructions. For example, the home therapy device 90 includes a control interface 1014. The control interface may include buttons, a control panel, or a touch screen. The control interface may be configured to enable a user to navigate to a certain window or user interface 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 devices 90, 104, and 106.

As shown in fig. 10, the example fluidic data transfer system 1000 includes a Web portal 150, a system hub 120, and a clinician server 200b (similar to the various devices discussed in conjunction with fig. 1-9) to communicate with a personal mobile communication device 200 a. The Web portal 150, system hub 120, and/or clinician server 200b transmit medical information (stored in the clinician database 1010) from the patient's medical record to the personal mobile communication device 200 a. Additionally, the Web portal 150, the system hub 120, and/or the clinician server 200b may provide the personal mobile communication device 200a with access to educational materials or a real-time help session with a clinician. The example Web portal 150, system hub 120, and/or clinician server 200b are also configured to enable the personal mobile communication device 200a to provide medical information for filling out patient medical records.

The example fluidic data transfer system 1000 of fig. 10 also includes a connection server 118, the connection server 118 communicatively coupled to the therapeutic home device 90. As discussed above in connection with fig. 1-9, the connection server 118 provides two-way communication between the home therapy apparatus 90 and the clinician server 200b and/or the clinician database 1010. The home treatment apparatus 90 may be connected to the connection server 118 via the internet.

In the example shown in fig. 10, the example 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 specify an application 1002 that, when executed by the processor 1016, causes the processor 1016 to provide features that improve patient engagement and/or compliance with therapy. Processor 1016 may include digital and analog circuitry configured as a microprocessor, application specific integrated circuit ("ASIC"), controller, and the like. Memory 1018 includes volatile and non-volatile storage media. Additionally, memory 1018 may include any solid state or disk storage media.

As discussed in more detail below, the features of the application 1002 include displaying treatment progress information, controlling which treatment programs the home treatment apparatus 90 runs, recording medical information, displaying instructional material, and/or initiating a help session with a clinician. The application 1002 may be rich or thin in functionality. The smartphone is configured with a feature rich application that utilizes native graphics, touch screen, and processing capabilities of the personal mobile communications device 200 a. Reduced functionality applications are configured to run on cellular telephones that have relatively less complex graphics and reduced processing power. Cellular telephones may also not include a touch screen or have a touch screen with limited functionality.

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

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

In some cases, an application 1002 on the personal mobile communication device 200a and/or an application 1020 on the clinician server 200b are configured to convert or otherwise provide medical information to a clinician database 1010 of other devices in the medical fluid data transmission system 1000 that are compliant with a health level 7 ("HL 7") standard (e.g., a medical standard). This conversion enables medical information to be stored in the HL7 format regardless of the format when entered on the personal mobile communication device 200 a. When there is a gap in the network or device connections, the application 1002 and/or the application 1020 can act as a network conduit to seamlessly propagate relevant medical information from the medical device to the patient medical records.

Fig. 11 illustrates a diagram of operational modules of the application 1020 at the clinician server 200b of fig. 10, according to an embodiment of the disclosure. The application 1020 may include a registration module 1102, the registration module 1102 configured to register patient medical records stored in the patient and/or clinician database 1010 with the home therapy apparatus 90 and/or the personal mobile communication device 200 a. As described in more detail in connection with fig. 12, registering may include determining the type of personal mobile communication device 200a that is formatted for subsequent communication.

The application 1020 may further include a data acquisition module 1104 configured to receive therapy and/or medical information from the registered home therapy apparatus 90 and/or the personal mobile communication device 200 a. Additionally, the application 1020 can include a data access module 1106 to transmit or otherwise provide access to medical information stored in one or more medical records associated with a patient. The application 1020 may also include an educational module 1108, the educational module 1108 configured to provide the patient with access to educational materials or help documentation regarding the treatment of the patient and/or the operation of the home therapy device 90. Further, the application 1020 may include a therapy control module 1110 that enables the patient (or clinician) to change (or modify) the therapy program executed by the home therapy device 90. The application 1020 may additionally include an assistance module 1112, the assistance module 1112 creating 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 participation in a medical fluid delivery therapy, thereby increasing patient compliance with a prescribed therapy. It should be appreciated that although the modules 1102-1112 are shown, the example application 1020 may include fewer or additional modules. For example, in some embodiments, education module 1108 and assistance module 1112 may be omitted. The following sections provide further description regarding each of the modules 1102-1112.

Each of the modules 1102-1112 is configured to communicate with the personal mobile communication device 200a and/or the clinician device 152, as described below. In some embodiments, communications from the personal mobile communication device 200a may be addressed 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 the different modules 1102-1112 based on content and/or identifier. For example, application 1002 may provide an identifier in a header to specify which of modules 1102-1112 receives the message. For text-based messages, the router at the clinician server 200b may determine the destination modules 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 sent by the data acquisition module 1104. Based on the 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 communication device 200a and/or the home therapy apparatus 90 with medical records of the patient stored in the clinician server 200b and/or the database 1010. The example registration module 1102 is configured to provide different types of registrations that are used by the data access module 1106 to determine how to display information to a patient based on what types of devices are registered. Additionally, the data acquisition module 1104 determines how to acquire the therapy and/or medical information based on the registration information.

The registration module 1102 is configured to store registration information to a registration file stored in the clinician database 1010. The registration file may specify, for each patient or patient activation code ("PAC"), information indicative of the registered personal mobile communication device 200a, information indicative of the registered home therapy apparatus 90, and/or an indication as to whether the application 1002 is installed on the personal mobile communication device 200 a. 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, the patient may register the personal mobile communication device 200a by downloading the application 1002 while also registering the home therapy device 90. In this case, the registration module 1102 records that the patient has installed the application 1002 on the personal mobile communication device 200a and registers the home therapy apparatus 90 (either separately or through the application 1002). Based on the registration, the data acquisition module 1104 determines that the application 1002 installed on the registered personal mobile communication device 200a will direct or otherwise prompt the patient to acquire medical information. In addition, the data acquisition module 1104 determines that treatment information is to be received from the home treatment apparatus 90 rather than via the personal mobile communication device 200 a. Accordingly, the data acquisition module 1104 may send a message to the application 1002 to disable the user interface for acquiring therapy information from the home therapy device 90 (but still enable the user interface for manual exchange if so prescribed for the patient). If the home treatment device 90 is not registered, the data acquisition module 1104 causes the application 1002 to display a user interface to acquire treatment information from the home treatment device 90 in the application 1002. By registering, the data access module 1106 determines that information is to be displayed by the application 1002 and accordingly reads components compatible with or configured for the application 1002 using APIs and/or other data.

If the patient is registered without downloading and/or installing the application 1002, the data acquisition module 1104 determines that data acquisition will be prompted or directed. For example, the data acquisition module 1104 may send a text message and/or an email to the registered personal mobile communication device 200a prompting the patient for certain medical and/or treatment information (if the home treatment apparatus 90 is not already registered). The information in the message specifies which data from the patient is needed. While this remote direction may be used with a reduced functionality personal mobile communication device 200a, it may also be used with smartphones where the patient does not wish to download or install the application 1002 on a rich functionality device.

The data access module 1106 can also be configured to display information from patient medical records differently if the application 1002 is not installed. For example, in addition to sending data that inserts a well-defined, functionally-rich user interface, the data access module 1106 may render the data in a picture that is communicated via text to the personal mobile communication device 200a for viewing. Additionally or alternatively, the data access module 1106 can transmit the stored medical record information as text to the personal mobile communication device 200 a. 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 200 a.

Fig. 12 shows a diagram illustrating communication between the home therapy apparatus 90, the personal mobile communication device 200a and the clinician server 200b of fig. 10 and 11, according to an example embodiment of the present disclosure. First, the home therapy device 90 registers with the clinician server 200b via the registration module 1102 of fig. 11. Otherwise, the clinician server 200b will not have information about which medical record data from the home therapy device 90 is to be stored. In some embodiments, the home therapy apparatus 90 is pre-programmed with destination address information for the connection server 118, the system hub 120, and/or the clinician server 200 b. 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 device 90. The PAC is initially generated and stored at the clinician server 200b and provided to the patient when the patient receives the home therapy apparatus 90. The PAC may include a patient identifier or other code unique to the patient. A registration module 1102 at the clinician server 200b stores the generated PAC to one or more medical records and/or registration files associated with the patient. After the PAC is input, the home therapy apparatus 90 generates and transmits a message 1202 including the PAC. The message may also include a hardware identifier of the home treatment apparatus 90 and/or an IP address assigned to the home treatment apparatus 90. The home therapy device 90 sends a message 1202 to the pre-programmed address, in this case the connection server 118. The example connection server 118 relays the message 1202 to the system hub 120, which the system hub 120 routes to the clinician server 200 b. The registration module 1102 at the clinician server 200b registers the home therapy device 90 with the patient using the PAC. Registration includes, for example, associating an identifier of the home therapy device 90 with a patient medical record of the patient. The registration may further comprise storing the clinician server 200b of the IP address of the home therapeutic device 90 to enable the message to be transmitted to the home therapeutic device 90. After registration, the data acquisition module 1104 of the clinician server 200b stores the therapy information received from the home therapy device 90 to one or more medical records associated with the patient.

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

In another embodiment, the message 1204 may enable the patient to register in two different ways depending on the capabilities and/or personal preferences of the personal mobile communication device 200 a. 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 reduced functionality device. A reply to message 1204 is provided via text message 1206, which is routed to 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, message 1204 may also beTo include text or hyperlinks to prompt the patient to select a hyperlink or otherwise obtain an application if desired. Message 1204 may also provide a prompt or option to select a device type, such asApparatus orAn apparatus. In 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 200 a.

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

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

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

B. Data acquisition Module embodiments

Figure 12 also shows data communication between the home treatment apparatus 90, the personal mobile communication device 200a and the clinician server 200 b. During operation, the home therapy apparatus 90 generates therapy information and status information (e.g., medical information). As discussed above in connection with fig. 1-9, the treatment information includes the amount of fluid injected, the amount of ultrafiltration ("UF") removed from the patient, and/or the treatment time. The status information includes alarm, reminder, or diagnostic information. Before or after treatment, the home therapy device 90 generates one or more messages 1208 with medical information, which are transmitted to the connection server 118. The connection server 118 then routes the message 1208 to the system hub 120, and the system hub 120 routes the message 1208 to the data acquisition module 1104 of the clinician server 200 b. Upon receipt, the data acquisition module 1104 stores the medical information in a designated portion of a patient medical record (e.g., the patient medical record 1302 of fig. 13). The message 1208 may include an identifier or address of the home treatment apparatus 90, which is used by the data acquisition module 1104 to locate the appropriate medical record in the database 1010.

The example home therapy device 90 may be configured to encode, tag, or otherwise identify the medical information being transmitted using metadata or other data identification techniques. The coding or labeling enables the data acquisition module 1104 (or an interface at the server 200 b) to determine the context of the medical information to write the medical information to the appropriate fields of the medical record. Additionally or alternatively, the code or indicia may also be stored in a record that is subsequently used to search for and display medical information.

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

Fig. 13 illustrates an example patient data structure 1300 stored on the clinician database 1010 of fig. 10, according to an example embodiment of the present disclosure. The patient data structure 1300 includes separate medical records for different patients. In the illustrated example, the data structure 1300 includes a patient medical record 1302 for the patient associated with the identifier "DCM 31913" and a patient medical record 1304 for the patient associated with the identifier "GAM 41215". The data structure 1300 can include additional patient medical records.

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

As also shown in fig. 13, medical records 1302 and 1304 include fields for treatment and medical information. The data acquisition module 1104 stores the treatment information in medical records 1302 and 1304 received from the respective home therapy devices 90. In addition, the data acquisition module 1104 stores medical information to medical records 1302 and 1304 received from the corresponding personal mobile communication device 200 a. In some embodiments, the data fields are further divided into separate fields for the data type. For example, medical records 1302 and 1304 can include treatment information fields for the amount of fluid infused, the amount of ultrafiltration ("UF") removed from the patient, and/or the time of treatment. The medical records 1302 and 1304 can also include data fields for reminders or alerts generated during treatment and/or data fields for alerts or reminders determined at the clinician server 200b based on treatment information and/or medical information. The medical records 1302 and 1304 can further include medical information of the patient's weight and/or blood pressure recorded before, during, and/or after treatment.

The treatment and/or medical devices may be organized by treatment, date/time of generation, and/or date/time of receipt. In some embodiments, the medical records 1302 and 1304 can store communications from the patient. The communication may include pictures or videos recorded by the personal mobile communication device 200a relating to the treatment or a problem with the treatment. The communication may also include a text message, email, etc. sent from the personal mobile communication device 200a regarding the treatment assistance. Further, the communication may include information related to a request 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 that improves patient engagement with treatment in addition to archiving treatment results and information related to patient engagement with treatment via the clinician server 200 b.

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

1. Manual input of medical information into application embodiments

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

Fig. 14 and 15 show diagrams illustrating a user interface of an application 1002 that enables a patient to enter medical information for transmission to the data acquisition module 1104. In particular, 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., therapy information). It should be appreciated that the application 1002 of the personal mobile communication device 200a may display other user interface screens that enable the patient to manually enter medical information. For example, the application 1002 may display user interface screens for blood glucose levels, patient temperature, patient weight, and the like.

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

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

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

In the illustrated embodiment, the user interface 1400 includes a systolic pressure data field 1402, a diastolic pressure data field 1404, and a pulse data field 1406. The patient can select the corresponding data field 1402, 1404, or 1406 to cause the application 1002 to display a text entry function to enter a value. The user interface 1400 also includes a field 1408 that enables the patient to specify whether to stand or sit for blood pressure measurements. Further, the user interface 1400 includes a data field 1410 that enables the user to specify the date/time that the blood pressure measurement was performed.

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

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 treatment, and/or if the home therapy apparatus 90 is not registered in the clinician server 200 b. Manual renal failure exchange therapy requires that the patient connect a dialysate container to his peritoneal cavity for an extended period of time, all without the aid of a machine, before spent dialysate is allowed to drain. For manual treatment, the patient needs to enter his manual exchange of medical information so that his medical history can reflect accurate treatment information.

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

In the illustrated example, the user interface 1500 includes the progress of the treatment, including a solution phase, a drain phase, a fill phase, a UF or dwell phase, and a summary phase. The application 1002 may display a separate user interface for each stage, prompting the patient to enter corresponding or requested treatment information. The example user interface 1500 corresponds to a UF stage, as indicated by a highlight 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 the volume of discharge into the data field 1504 during the discharge phase and to enter the volume of discharge into the 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 the value.

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

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

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

2. Embodiment for wirelessly inputting medical information into application

In some embodiments, the patient may choose to enter medical information wirelessly in their personal mobile communication device 200 a. Can be via, for exampleIs connected with,Is connected with,The connection, wireless USB connection, wireless RF connection, NFC connection, infrared connection, or any other suitable wireless communication technology, receives medical information in the personal mobile communication device 200 a. In some cases, the patient may have to wirelessly pair the personal mobile communication device 200a with a medical device, such as the blood pressure monitor 104 and/or the weight scale 106. In other embodiments, the patient activates a connection application (e.g., NFC application) that wirelessly reads medical information from the medical device.

In an example, a patient may pair their personal mobile communication device 200a with the 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 pressure data field 1402. Selection of field 1402 causes application 1002 to display a request for the patient to select a data entry method (e.g., an example)E.g., manual, wireless, photo, etc.). After selecting the wireless option, application 1002 displays a menu of available wireless connection options and/or paired A list of 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 pressure, which causes a systolic pressure value to be filled into the systolic pressure data field 1402. In some embodiments, the application 1002 is configured to read medical information from the blood pressure monitor 104 after the patient selects a device. The application 1002 may use data tags or metadata to determine which of the fields 1402-1410 are to fill in medical information from the blood pressure monitor 104.

In some embodiments, the application 1002 is configured to enable a patient to establish a permanent or semi-permanent connection with a medical device. During a setup operation, the application 1002 prompts the patient to select a data field from the user interface 1400. After selection, the application 1002 prompts the patient to select a paired wireless medical device (and/or select a data type from a menu associated with the medical device). The patient's selection configures the application 1002 to automatically read medical information from the blood pressure monitor 104, for example, when new medical information is available. In other words, the application 1002 is configured to automatically wirelessly access the telemedicine device to read certain medical information to fill in one or more data fields. For example, after the patient uses the blood pressure monitor 104 to make a blood pressure measurement, the monitor 104 sends 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 if new data is available. Application 1002 then reads the new data into one or more of data fields 1402-1410 to automatically fill out user interface 1400. The application 1002 then sends the medical information to the data acquisition module 1104 of the clinician server 200b to automatically update the patient's medical record.

3. Entering medical information images into application embodiments

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

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

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

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

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

The example data processor 1602 may be configured to manage the acquisition of medical information from one or more images. Such management includes displaying one or more camera messages via the screen 1002 that provide information prompting a clinician or patient (e.g., operator) to record certain images. Alternatively, the data processor 1602 may initialize the image processing mode after the patient has selected to use the image entry method to enter medical information into one or more data fields of the application 1002. After selecting 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 communication device 200a to open a camera application to enable the patient to record one or more images. The patient can choose which recorded image to process further or discard. The selected images are analyzed to identify text (as medical information) for data fields that may be populated into 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 for acquiring images. The data processor 1602 may execute a workflow or routine based on which data fields are selected by the patient. For example, the data processor 1602 selects the systolic pressure data field 1402 to perform a blood pressure workflow for obtaining images from a blood pressure monitor based on the patient.

In an example, the data processor 1602 of fig. 16 is configured to display a camera message that identifies a medical device, a user interface window of the medical device, and/or an identifier on the medical device to be recorded. The data processor 1602 may also display a navigation message specifying a user interface window of the medical device for imaging. Further, the data processor 1602 may display a reminder message if no image is recorded for a predetermined period of time (e.g., five minutes). The message may include text that provides instructions and/or identifies the intended target for imaging. The message may also include instructions on how to navigate to a certain user interface window of the medical device using the control interface of the medical device. The message may further include graphical elements such as an exemplary illustration of the medical device, the consumable, the identifier 1012, and/or a user interface window for which images are 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 reacts to the images recorded by the patient to determine relevant medical information. For example, upon receiving an indication to record an image, the data processor 1602 operates a workflow in which the application 1002 prompts the clinician to identify a medical device from which an image has been recorded. The prompt may include a drop down menu of available or common medical devices. In other examples, the data processor 1602 automatically identifies medical information using one or more data templates or data tags to determine which extracted medical information is to be filled in or written in data fields of a user interface or medical record.

To record an image, the example data processor 1602 and the image processor 1604 (more generally, the processor 1016) provide operations for the application 1002 in conjunction with the camera 1004. The patient provides instructions via the camera user interface 1606 (e.g., a touch screen or buttons on the personal mobile communication device 200 a) to record the image. For example, when the camera is focused on the medical device user interface window or identifier 1012, the patient launches the camera user interface 1606. The data processor 1602 receives the indication and instructs the camera 1004 to record an image. The recorded image is transferred from the camera 1004 to an image processor 1604. Additionally, a copy of the image is displayed by the data processor 1602 on the display interface 1022 of the personal mobile communications device 200 a.

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

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

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

In addition to performing OCR to recognize text, the image processor 1604 may be configured to recognize patients, medical devices, and/or consumables using image analysis. For example, the image processor 1604 may access a library of medical device images to identify the medical devices within the images. In this example, image processor 104 may use an image matching routine to determine a match. Such a comparison may be made in place of the medical device having the identifier 1012. The image processor 1604 may use similar routines and/or algorithms to identify the consumable 1006.

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

The example image processor 1604 of fig. 16 communicates images with extracted or otherwise identified text and/or medical information to the data processor 1602. The example data processor 1602 identifies relevant medical information from the extracted text using one or more data templates, for example, from the data template database 1608. In some examples, the data processor 1602 receives the data template 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 having data templates.

Fig. 17 shows a schematic diagram of a data template 1700 according to an example embodiment of the present disclosure. An image processor 1604 (e.g., application 1002) uses the example data template 1700 to identify the extracted text as relevant medical information. Typically, a screen of the medical device displays medical information. Some information is related to the data field contents of the user interface of application 1002. Other data may be less or unrelated. Further, the medical information may be located in different locations or have different labels depending on the model of the medical device. The data template 1700 is configured to specify the location and name of the relevant medical information for a particular home therapy device 90.

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

The example data template 1700 of FIG. 17 includes device data (or text) fields 1702, 1704, 1706 and 1708 that specify that certain medical information is located on a particular user interface window of a medical device. In some examples, the data template 1700 is graphical such that image analysis is performed to align the fields 1702-1708 with extracted text in an image. In other examples, the data template 1700 includes a file (or other data structure) having coordinates or locations of each of the device data fields 1702 through 1708 relative to an origin. The image processor 1604 uses the extracted text to identify an origin in the image based on a substantial match with a location in the data template 1700, and identifies text for each of the data fields 1702-1708. 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 tag text in addition to coordinates and/or location. For example, the device data field 1702 includes the tag text "ultrafiltration window" and the device data field 1704a includes the tag text "UF Vol". The image processor 1604 matches the tagged text with similar text extracted from the image. In some cases, the match between tag texts is used only to identify device data fields, rather than using location or image analysis.

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

The tag text associated with the device data fields 1706 and 1708 may be used to confirm that the recorded image is current or recorded within a determined period of time. For example, some windows of the medical device 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 with date/time rules or restrictions associated with the device data fields 1706 to 1708 to determine whether the recorded image is current. For example, if the dates do not match or the time is not within a predetermined threshold of the current time on the personal mobile communication device 200a (e.g., 5 minutes, 15 minutes, 60 minutes, 3 hours, etc.), the image processor 1604 may determine that another image needs to be recorded.

The application 1002 identifies relevant medical information using the example device data fields 1704a and 1704b of fig. 17. In some cases, the application 1002 may display a flag or metadata indicating that the device data fields l704a and l704b are related to a selected data field of a user interface (e.g., user interface 1400 or 1500). By comparison, the device data fields 1702, 1706, and 1708 may include flags or metadata indicating that the respective extracted data is not relevant. In the example shown in FIG. 17, the image processor 1604 uses the label text of the data field 1704a to locate corresponding extracted text in the image. Then, the image processor 1604 uses the positional relationship between the device data fields l704a and l704b or text value labels to identify extracted medical information from the image that corresponds to the value of the ultrafiltration volume. The image processor 1604 copies the extracted medical information from the image relating to field 1704b to fill out, 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 positional relationships of text in the image and text labels to determine which of the extracted text corresponds to relevant medical information. In some embodiments, the data processor 1602 selects the data template based on an indication of the model or type of medical device and/or consumable. The indication may be determined by a previous image of the identifier 1012 received from the patient via the camera user interface 1606 and/or specified by selecting a data field of a user interface for the application 1002 that will fill in the medical information. In other examples, the data processor 1602 compares the data templates in the database 1608 with the images with the extracted text to find a match. In these other examples, the data processor 1602 uses the text labels and the text positions between the images and the data templates to determine a match.

The example data processor 1602 is configured to, after identifying relevant medical information, write or otherwise fill in the relevant medical information into one or more data fields of a user interface of the application 1002. In some embodiments, the data processor 1602 is configured to automatically fill in data fields of a user interface of the application 1002 using a data template. To automatically fill in medical information, the data processor 1602 compares text, tags, and/or metadata associated with fields of the data template to text, tags, metadata, and/or other data field information of one or more user interfaces of the application 1002. If at least some of the text, tags, and/or metadata match, the data processor 1602 identifies certain text (e.g., numerical values) that correspond to the matching fields of the data template. The identified text is written into the corresponding matching data field of the user interface of 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 to fill out one or more data fields of the user interface of the application 1002. Fig. 18 shows a diagram illustrating a patient filling out data fields 1402-1406 of a user interface 1400, according to an example embodiment of the present disclosure. In the illustrated example, the user interface 1400 is opened on the personal mobile communication device 200 a. To enter medical information into the data fields 1402-1406, the patient selects each data field sequentially or together. For each selection, the application 1002 displays a prompt asking the patient how to enter data. After the patient selects the photo entry method, the application 1002 opens the camera application to enable the patient to record an image 1800 of the screen of the blood pressure monitor 104 using the personal mobile communications device 200 a. In some embodiments, as described above, the application 1002 may display text or graphics to assist the patient in acquiring the image.

After recording the image 1800, the application 1002 performs an OCR operation to extract text. The application 1002 then determines a data template 1801 corresponding to the extracted text. In some embodiments, the application 1002 matches the location of text and/or tags within the image to the text and/or tag locations in the data template to find a matching data template. In other examples, the patient may specify an indication of the blood pressure monitor 104, which allows the application 1002 to locate the corresponding data template 1801. In other examples, the application 1002 may first prompt the patient to record an image of the identifier 1012a of the blood pressure monitor 104. 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. The process includes the application 1002 identifying groups or fields of similar text. In some cases, the application 1002 may identify groups or fields of similar text based on the spacing between letters and/or words.

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

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

FIG. 19 shows a flowchart of an example process 1900 for inputting medical information from an image using an application 1002 of a personal mobile communication device 200a, according to an example embodiment of the present disclosure. Although process 1900 is described with reference to the flowchart shown in FIG. 19, it should be appreciated that many other methods of performing the steps associated with process 1900 may be used. For example, the order of many of the blocks may be changed, some blocks may be combined with other blocks, and many of the blocks described may be optional. Additionally, the example process 1900 may include an optional box for prompting the patient to record a screen of the medical device and/or an image of the identifier 1012.

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

Prior to block 1906, the patient uses the application 1002 to select data fields and to select that medical information is to be provided via photo entry. At block 1906, the personal mobile communications device 200a records an image 1907 of the medical device, consumable, patient, etc. The image may include an identifier of the medical device and/or a screen. The personal mobile communication device 200a then determines or identifies text within the recorded image (block 1908). For example, the personal mobile communication device 200a may perform an OCR routine on the image. Where the image includes a barcode and/or QR code, the personal mobile communication device 200a decodes the barcode and/or QR code. The imaged or encoded data is converted to texture or american standard code for information interchange ("ASCII") characters. In some embodiments, the personal mobile communication device 200a may also determine a data field for the identified text (block 1910). The data fields may be determined using, for example, a data template. As described above in connection with fig. 17 and 18, the data template may specify the location of certain text and/or specify tags for certain text that are used to operatively place data fields on the recognized text within the recorded image. In some cases, the data fields and/or data templates may be selected by the patient and/or determined by the identifier 1012 of the medical device. Alternatively, rather than using a template, the process 1900 may provide an indication that the most recently recorded image has relevant medical information for extraction, selection, and/or transmission.

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

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

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

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

4. Image/text attachment application embodiments

In some embodiments, the example application 1002 and the clinician server 200b are configured to enable a patient to provide images or text as an attachment or appendix to their medical history. In the above section, the application 1002 provides the data fields of the user interface as a prompt for the 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 do you feel today"), or features that enable photographs or images to be incorporated into a portion of the record. For example, the user interface 1400 may include a photo icon adjacent to a prompt for an image fluidly connected to the patient's abdomen that, when selected, will turn on the camera application to enable the patient to attach an image for transmission with medical information. The image can be stored in a design field in an appropriate patient medical record.

An example application 1002 on the personal mobile communication device 200a is configured to accept images and/or text provided by a patient. In an embodiment, the application 1002 is configured to enable the patient to select between text or photo entry. If the patient selects text entry, the application 1002 displays a text box. The patient enters information into a 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 200 b. The application 1020 on the clinician server 200b determines the appropriate patient medical record in the database 1010 and locates the "notes" or free text fields. The application 1020 stores the patient-provided text in this field. In some cases, the application 1020 may also include a time/date stamp with the entered text. This information provides the clinician with additional information from the patient, including feedback regarding the treatment.

Fig. 20 shows an example of a user interface 2000 that may be displayed by an application 1002 on the personal mobile communications device 200a, the user interface 2000 enabling the patient to provide recorded images, according to an example embodiment of the present disclosure. The example user interface 2000 includes an image title field 2002, which may be edited by the patient. The user interface 2000 also includes one or more recorded images 2004, or previews of recorded images. The application 1002 is configured to enable the patient to browse a gallery folder of recorded images to select which images to transfer. The date field 2006 and time field 2008 provide information indicating the date/time at which the displayed image was recorded in the user interface 2000. The patient may select a "trash can" button to discard the image 2004, or may select an "upload" button to transfer the image 2004 from the application 1002 to the clinician server 200 b. The example photo capture feature of the application 1002 enables the patient to document a physiological condition associated with a fluid line connection of the home therapy device 90 or with a therapy. The application 1020 at the clinician server 200b is configured to append or otherwise link the received image 2004 to a medical record of the patient.

5. Manual/wireless/image entry medical information via text embodiments

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

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

The example data acquisition module 1104 of fig. 11 is configured to format or otherwise construct received information for populating into one or more data fields of a patient medical record. Typically, the medical information received from the text message is unstructured. In other words, the text message does not provide explicit associations or references to the design fields of the patient medical record. Instead, the data acquisition module 1104 is configured to determine the appropriate field of medical information received in the text message.

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

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

In other embodiments, the data acquisition module 1104 prompts the patient to provide certain medical information through a series of messages (which may be defined by a routine or algorithm). The order of the sequence is known or defined and corresponds to the data fields in the medical record. Thus, the data acquisition module 1104 automatically determines that a response to a prompt corresponds to a data field of a medical record associated with the prompt. For example, the data acquisition module 1104 sends a text message prompting the patient to make a "systolic blood pressure measurement". The data acquisition module 1104 determines that the response to the text contains a value for "systolic blood pressure measurement". The data acquisition module 1104 may analyze the received message to identify a value in other text and/or compare the value to an acceptable range. After confirming that the patient provides 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.

In addition to receiving messages with text, the data acquisition module 1104 can also receive messages with photo attachments. Similar to the process described above in connection with fig. 16-19, the data acquisition module 1104 is configured to process the images to extract text and identify relevant medical device data for one or more data fields of a medical record. Further, although the above disclosure describes using text messaging, the data acquisition module 1104 may additionally or alternatively receive medical information and/or photographs via other communication media such as email, instant messaging or Web-based messages, social media posts, and the like.

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

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

It should be appreciated that in other embodiments, the patient medical template 2100 may include more or fewer fields. For example, template 2100 may additionally include data fields for pre-treatment and post-treatment patient weights, patient glucose levels, and/or patient birth dates. In another example, the template 2100 may include fields for fill-out rate, dwell time, drain or fluid removal rate, blood flow rate, outflow dose, ultrafiltration removal rate, dialysate removal rate, total dialysate infusion infused, dialysate flow rate, pre-change flow rate, post-change flow rate, patient weight balance, return pressure, excess patient fluid, filtration fraction, time remaining, dialysate concentration, dialysate name, patient identifier, room identifier, care area identifier, timestamp indicating when data was generated, alarm condition, reminder condition, and/or event.

In some embodiments, the data acquisition module 1104 is configured to select the template 2100 based on a prompt from the patient. For example, the patient may send a message including a "manually exchanged" text to the data acquisition module 1104. 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 including text of "before treatment" or "start treatment" to the data acquisition module 1104 via the personal mobile communication device 200 a. In response, the data acquisition module 1104 identifies and selects a template for acquiring the required medical information before treatment begins.

In the example shown in fig. 21, example data fields include a field 2102 for patient name, a field 2104 for patient identifier, a field 2106 for patient weight, a field 2108 for patient blood pressure, a field 2110 for treatment date, a field 2112 for removing UF volume, a field 2114 for total amount of fluid provided to the patient, a field 2116 for glucose level, a field 2118 for treatment prescription identifier, and a field 2120 for disposable cassette identifier. In the event that the renal therapy machine 90 is registered with the clinician server 200b, the data acquisition module 1104 may at least remove the fields 2112 through 2120 (or choose to omit a separate template having the fields 2112 through 2120) because such information is already provided by the machine 90. However, if the patient is reporting a manual replacement, fields 2112 through 2120 may be used in the template. Further, template 2100 may omit fields 2102 and 2104 based on at least some patient information that has been registered.

Example data fields of the patient medical template 2100 may be populated from one or more different sources of medical information, including device information, patient information, and/or consumable information. For example, the patient name field 2102 and 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 filled from images recorded by the personal mobile communications device 200a of the screen of the blood pressure monitor 104, while the weight field 2106 may be filled from images recorded by the personal mobile communications device 200a of the screen of the scale 106. The date field 2110, removed UF field 2112, and fluid fill field 2114 may be filled in from images recorded by the personal mobile communication device 200a of the screen of the home treatment apparatus 90 (showing the treatment status window). Similarly, the right-handed glucose level field 2116 may be filled from an image recorded by the personal mobile communication device 200a of the screen (showing the setup window) of the home treatment apparatus 90, while the prescription identifier field 2118 may be filled from an image recorded by the personal mobile communication device 200a of the screen (showing the prescription window) of the home treatment apparatus 90. Finally, the cartridge identifier field 2120 may be populated from the image recorded by the personal mobile communication device 200a of the identifier 1008 of the disposable cartridge consumable 1006. As described above, the data acquisition module 1104 may receive one or more messages having text for the fields 2102 to 2120, in addition to receiving images containing medical information.

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 fig. 10 and 11. Upon receiving a request to fill out a template for a patient, the clinician server 200b is configured to make a copy of the template 2100 or to create an instance of the template 2100. Medical information received from the personal mobile communication device 200a is entered by the data acquisition module 1104 into the appropriate data fields 2102 to 2120 of the copy or instance of the template 2100. Once completed, the copy or instance is stored as a patient's medical record in the clinician database 1010 repository.

In some embodiments, the data acquisition module 1104 operates the routine 2150 in conjunction with or in place of the example patient medical template 2100. In some embodiments, routine 2150 may be programmed as metadata or computer-executable code for each of data fields 2102-2120. In other examples, the routine 2150 may be stored in the clinician database 1010 in relation to the patient medical template 2100. Further, in these other examples, selecting the template 2100 causes the routine 2150 to be executed. The example routine 2150 includes routine modules 2152-2164 that provide associations between the data fields 2102-2120 and the respective medical devices, identifiers 1012, and/or consumables 1006.

At least some of the routine modules 2152-2164 may be associated or otherwise related to a data template (e.g., the data template 1700 of fig. 17). The data acquisition module 1104 is configured to access data templates for the respective routine modules 2152-2164 when the patient provides images and/or text in the message. For example, while executing the routine module 2156 for blood pressure, the data acquisition module 1104 sends a message prompting the personal mobile communication device 200a to make a "systolic blood pressure measurement". The patient responds with a text message containing an image of the screen or dial of the sphygmomanometer 104. The data acquisition module 1104 is configured to access a data template corresponding to or referenced to the routine module for blood pressure measurement 1156. The data acquisition module 1104 then applies the data template to extract text from the image using the process described above in connection with fig. 16-19 to identify relevant systolic blood pressure medical information for filling in the blood pressure data field 2108 of the template 2100.

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

In the example shown, the patient ring module 2152 may include metadata or a pre-formatted message instructing the patient to record an image of the patient's wristband. The patient ring module 2152 may also include a character validation check to ensure that the received medical information conforms to the textual requirements of the patient's name and/or patient identifier. For example, the patient ring module 2152 may reject or discard medical information including the patient's name of the number.

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

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

The cartridge module 2164 may include metadata or pre-formatted messages that indicate images of the clinician or patient record identifier 1008, the disposable cartridge consumable 1006, and/or the label on the package or cartridge consumable itself. It should be appreciated that routine 2150 may include additional modules if patient medical template 2100 includes additional data fields, or routine 2150 may include fewer modules if template 2100 includes fewer fields.

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

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

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

Fig. 22 is a schematic diagram of the data acquisition module 1104 of the clinician server 200b of fig. 11, according to an example embodiment of the disclosure. It should be appreciated that the illustration of the data acquisition module 1104 is exemplary and that some blocks may be combined, further divided, or eliminated. Additionally, in some embodiments, the data acquisition module 1104 may include additional boxes, such as boxes for a user interface.

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

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

The example template processor 2204 is configured to identify messages from modules of a routine (e.g., the routine 2150) for transmission to the personal mobile communication device 200 a. In some cases, messages may be transmitted in a predetermined order to guide or guide a clinician or patient through the process of filling out a patient medical template. For example, the template processor 2204 may read the module 2156 of routine 2150 of fig. 21 and determine a message to transmit prompting 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 (for filling out the data field 2106 of figure 21) relating to the identifier 1012c is received before identifying the message from the routine module 2156 to be transmitted. In other cases, the template processor 2204 selects a message to send based on the message received from the personal mobile communication device 200 a. For example, the processor 2204 may receive medical information associated with the identifier 1012c of the weight scale 106. In response to the received medical information, the template processor 2204 may determine that the module 2154 corresponds to the received data and select a message accordingly that prompts the patient to record an image of the screen of the weight scale 104. As shown in fig. 22, the personal mobile communications device 200a displays a text message from the template processor 2204 instructing the patient to record an image of the screen 2220 of the weight scale 106.

In addition to sending messages, the template processor 2204 may be configured to select data templates. In the illustrated embodiment, the data templates are stored in a data template database 2208. The template processor 2204 selects a data template based on the type or model of 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 a message. Further, as described above, the template processor 2204 may receive images from the personal mobile communication device 200a, extract text from the images, and select appropriate data templates from the database 2208 to identify relevant medical information from the image(s) as described above.

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

After filling out or otherwise completing the patient medical template, the template processor 2204 of fig. 22 is configured to store the completed template to the clinician database 1010. This can include filling in the patient's medical record using the template 2100, where fields in the template correspond to, link to, or reference fields in the patient's medical record. In other examples, writing the medical record may include storing the filled-in template into the patient's medical record or storing the template 2100 as the medical record itself.

Fig. 23 and 24 are flow charts of example processes 2300 and 2350 for populating the medical device template 2100 of fig. 21 using images recorded by (and/or text messages received from) the personal mobile communications device 200a of fig. 10 through 12 and fig. 22, according to example embodiments of the present disclosure. Although the processes 2300 and 2350 are described with reference to the flow diagrams illustrated in fig. 23 and 24, it should be appreciated that many other methods of performing the steps associated with the processes 2300 and 2350 may be used. For example, the order of many of the blocks may be changed, some blocks may be combined with other blocks, and many of the blocks described may be optional. In an embodiment, the order of the blocks may be modified if there is no permanent connection between the clinician server 200b and the personal mobile communication device 200 a. Rather, in an embodiment, the personal mobile communication device 200a may first acquire and queue substantially all relevant medical information for the patient medical template until a connection with the clinician server 200b is available (or as designed). The actions described in processes 2300 and 2350 may be performed by between a plurality of devices including, for example, the personal mobile communication device 200a and the clinician server 200 b.

The example process 2300 begins in fig. 23 when the clinician server 200b of fig. 10-12 and 22 receives a message 2301 from the personal mobile communication device 200a (block 2302). Message 2301 indicates a treatment to be performed on the patient or a request to begin transmitting 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 therapy type specified in the message 2301 or the prescribed therapy specified in the patient medical record (block 2304). In the case where the clinician server 200b provides only one type of template for completion (e.g., a template for renal failure therapy), the message 2301 may indicate a request to begin filling in a blank template. In response to message 2301, clinician server 200b creates a copy of the patient medical template for filling out.

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

The example process 2300 continues in fig. 24 where 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 specified by the message 2307. Further, the second camera message 2313 may include information for displaying a certain window (or related medical information) on the medical device used to record the image. Some time later, the clinician server 200b receives a message 2315, the message 2315 including text or images from the window of the medical device (block 2316). The example clinician server 200b extracts relevant medical information from the image using the identified data template and determines or otherwise identifies data fields of the patient medical template corresponding to the relevant medical information (block 2318). If the message 2315 includes text, the clinician server 200b determines or otherwise identifies a data field in the patient medical template corresponding to the relevant medical information. Next, the clinician server 200b populates the data fields of the determined and/or identified template with the received relevant medical information (block 2320).

After filling in the relevant data fields, the example clinician server 200b determines whether additional relevant medical information is needed from the medical device associated with the received relevant medical information (decision block 2322). For example, the clinician server 200b may determine that the current medical device may include additional windows or operational displays from which relevant medical information still needs to be obtained. If additional medical information is needed, the example clinician server 200b returns to block 2314 and transmits a camera message 2313 for another window for which relevant medical information is needed. However, if additional medical information for the current medical device is not needed, the clinician server 200b determines if medical information from other medical devices (or consumables 1006) is needed (decision block 2324). If additional medical information is needed, the clinician server 200b returns to block 2306 and transmits a camera message 2305, the camera message 2305 identifying another medical device for imaging or receiving relevant medical information therefrom. If additional medical information is not needed to complete the patient medical template 2100, the example clinician server 200b stores the completed patient medical template 2100 to the clinician database 1010 as a medical record of the patient and the process 2300 ends.

The example process 2350 begins in fig. 23 by the personal mobile communication device 200a transmitting a message 2301 indicating a request to perform a treatment on a patient or to begin entering medical information (2352). Next, the personal mobile communication device 200a receives the camera message 2305 from the clinician server 200 b. The personal mobile communication device 200a uses the information from the message 2305 to display a prompt to the patient (block 2354). The prompt may specify, for example, an identifier 1012 of the medical device to be imaged. The personal mobile communication device 200a then records an image of the identifier 1012 of the medical device based on input from the patient (block 2356). In some embodiments, if the identifier is not available or the patient does not want (or is unable to) record images, the patient may enter text specifying the medical device type/model or select from a drop-down menu.

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

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

In fig. 24, the example process 2350 continues with the personal mobile communication device 200a creating a text message with the recorded image or text entered by the patient (block 2364). In some examples, the patient may modify or specify medical information. The personal mobile communication device 200a then transmits a message 2315 that includes the medical information or image thereof (block 2366).

Next, the example personal mobile communication device 200a determines whether additional relevant medical information is needed from the medical device associated with the extracted relevant medical information (decision block 2368). This determination may include, for example, checking to see if additional camera messages related to the current medical device are received from the clinician server (block 2360). If additional medical information is needed, the example personal mobile communication device 200a returns to block 2360 and processes the camera message 2313 for another window (or portion of the medical device/consumable) for which relevant medical information is needed. However, if additional medical information is not needed for the current medical device, the personal mobile communication device 200a determines if medical information from other medical devices (or consumables 1006) is needed (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 additional medical information is not needed to complete the patient medical template, the example personal mobile communication device 200a ends the session, ending the process 2350.

6. Manual/wireless/image medical information entry via Web browser or file transfer

In some embodiments, the data acquisition module 1104 of fig. 11 is configured to enable a patient to use their personal mobile communication device 200a to enter medical information or provide images via a Web browser or file transfer program. The Web browser or file transfer program enables the personal mobile communication device 200a to provide medical information and/or images without the use of the application 1002. In this embodiment, the clinician server 200b hosts a website, API, and/or file transfer site that is assigned an address or uniform resource locator ("URL"). The Web browser or file transfer program on the personal mobile communication device 200a is configured to access a hosted website, API, and/or file transfer site to communicate 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 and provides access to personal mobile communication devices 200a that have previously registered. In other embodiments, the data acquisition module 1104 provides a mailbox or other interface (e.g., API) to receive medical information or images without providing the personal mobile communication device 200a with access to a more secure location.

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

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

Fig. 25 shows a diagram of a clinician server 200b hosting a website or file transfer site to receive medical information via images from a personal mobile communication device 200a according to an example embodiment of the disclosure. In the illustrated example, the personal mobile communication device 200a is operating a Web browser application 2500 that is directed to a website 2502 hosted by the clinician server 200 b. 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 the data template 1801 to the image to extract a text set, as shown by fields 1802, 804, 1806, 1808, and 1810. The patient selects fields 1802, 804, 1806, 1808, and 1810 to be filled in with text in one or more selected data fields of website 2502. In this manner, the clinician server 200b enables the patient to provide medical information via a website, file transfer program, or API(s).

C. Data access module embodiments

Returning to fig. 11, the example data access module 1106 is configured to provide the patient and clinician with access to medical information stored in medical records of 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 in which the application 1002 may or may not be installed. The data access module 1106 is configured to provide access or otherwise display data based on the configuration. To determine which configuration a particular patient is using, the example data access module 1106 is configured to access a registry or patient's medical records to identify registered personal mobile communication devices 200a and/or whether applications 1002 are installed.

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

The example data access module 1106 can also determine whether to convert medical and/or treatment information in the patient medical record to a different format prior to transmission. For example, medical information and/or treatment information may be stored in a medical record in the HL7 format. However, this format is not conducive to text messaging and/or applications. The example data access module 1106 determines the capabilities of the personal mobile communication device 200a to which to communicate the data. Data accessThe questioning module 1106 determines 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 medical information on application 1002, data access module 1106 converts the medical information and/or treatment information from an HL7 format to, for example, a Hypertext markup language ("H") using one or more APIs^TML "), JavaScript object notation (" JSON ") format, or XML format (e.g., application format). If the data access module 1106 determines that the application 1002 is not installed, the data access module 1106 converts the information from the HL7 format to a text message or SMS message format via, for example, one or more APIs. Thus, the example data access module 1106 enables a patient to view patient medical record information regardless of the capabilities of their personal mobile communication device 200 a.

1. Information display embodiment via application

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

Fig. 26-29 show diagrams of applications 1002 on the personal mobile communications device 200a displaying medical information provided by the access module 1006, according to an example embodiment of the present disclosure. The application 1002 may be configured to display different user interfaces 2600, 2700, 2800, and 2900 upon patient selection. In some cases, the application 1002 provides a menu or other selectable graphical feature that lists the different user interfaces that are available. The application 1002 can be configured to receive medical information via one or more APIs linked to data fields of a patient medical record. In other words, medical information from medical records is inserted into blank templates that define a graphical user interface for displaying medical information.

The user interface 2600 of fig. 26 provides a first graph 2602 and a second graph 2604, the first graph 2602 showing total UF removed per day, and the second graph 2604 showing average UF removed per individual diurnal exchange. It should be appreciated that the medical information displayed in graphs 2602 and 2604 may originate from the home therapy apparatus 90 and/or one or more medical devices. The data access module 1106 of the clinician server 200b provides access to medical information from different sources, providing information transparency to the patient, whenever the information has been stored in the patient's medical record.

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

The example user interface 2700 of fig. 27 shows the average drain time for each UF exchange. The drain time is provided in chart 2702. Between user interfaces 2600 and 2700, the patient can assess the progress of the treatment over time. Any deviation in treatment should be apparent and help persuade patients to adhere to the prescribed treatment.

The example user interface 2800 includes a calendar that indicates the number of days that the patient adheres to the treatment or therapy as compared to the number of days that the patient does not adhere to the treatment. The patient may select one of the days to view additional medical information. For example, user interface 2900 displays treatment or medical information for 4 months and 26 days. This information includes, in addition to the UF particulars removed during the manual exchange compared to the UF removed via the home treatment apparatus 90, the total amount of UF removed during the day. In the illustrated embodiment, the machine treatment information includes the program name, the prescribed treatment time, the actual treatment time, and the amount of UF removed. The data access module 1106 can determine whether to adhere to treatment based on the actual treatment time being within a threshold of the prescribed treatment time. In some embodiments, the data access module 1106 and/or the data acquisition module 1104 can determine adherence upon receipt of medical or treatment information and set a corresponding flag or other indication in the patient's medical record to reflect the adherence or non-adherence.

In some examples, the patient enters therapy information for manual exchange via the application 1002 on the personal mobile communication device 200a while receiving machine therapy information separately from the home therapy apparatus 90. In other examples, user interface 2900 may display treatments that occur in the patient's home as well as treatments that occur in a clinic. The information may be organized based on the machine receiving the information, program name, treatment type, prescription, etc. The user interface 2900 in the illustrated example accordingly provides a single display of UF removed for different exchanges, providing the patient with information regarding the effectiveness of manual exchanges compared to exchanges of machine operation. The example system 100 of fig. 10 enables information from both exchanges to be stored together (based on treatment day) for subsequent display and/or analysis.

2. Information display embodiment via Web browser

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

3.Information display embodiment via text

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

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

4. Alarm/reminder 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 alerts and/or reminders for patients and/or clinicians. The data access module 1106 can send alerts and/or reminders to the patient's personal mobile communication device 200a or clinician device 152. In some embodiments, the data access module 1106 may include a rule table that specifies to which devices certain alerts/reminders are to be sent. The clinician may subscribe to certain alerts/reminders and/or patients using the clinician device 152.

The data access module 1106 is configured to provide alerts/reminders based on how the personal mobile communication device 200a is configured to display medical and/or treatment information. For example, if the application 1002 is installed, the data access module 1106 provides alerts/reminders through an appropriate user interface of the application 1002. In some cases, the application 1002 is configured to display a notification indicating an alarm/reminder. If the application 1002 is not installed, the data access module 1106 determines to transmit an alert and/or reminder 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 specifies certain conditions under which alerts or reminders are to be generated. In an example, a condition may compare a single data value or trend (e.g., a 30-day moving average) to a range of acceptable values and/or thresholds (which may include hard limits and/or soft limits). In other examples, alerts or reminders 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 derivative information calculated from the treatment and/or medical information, which is then compared to an acceptable range. Examples of alerts/reminders that may be transmitted via text messaging and/or displayed within the application 1002 by the data access module 1106 are provided below.

In an example, the data access module 1106 can generate an alert or reminder if it is detected that the patient begins to deviate from the prescribed treatment. For example, after detecting that two days have elapsed since the receipt of the therapy information, the data access module 1106 transmits an alert message (operating according to alert rules) to the personal mobile communication device 200 a. For example, the reminder message specifies that the patient should perform the treatment. The reminder message may also include information (or information links) describing why the treatment is important, or what happens to the patient's body if the treatment is not done in time. If the data access module 1106 detects that treatment information has not been received, for example, four days, the data access module 1106 raises the reminder to an alarm (operating according to alarm rules). The data access module 1106 communicates an alert to the personal mobile communication device 200a and/or the clinician device 152 to provide an indication of the severity of non-adherence to treatment. As described above, alerts and/or reminders are communicated 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 mark the patient's attention.

In some examples, the patient is prescribed a manual exchange. Therefore, the patient must provide treatment information indicating the manual exchange. The data acquisition module 1106 is configured to send an alert or reminder if no manually exchanged information is received within a predetermined time period (e.g., within 2 days after a predetermined treatment). Further, if the manual exchange is not completed properly (e.g., a short fill-in or dwell time), the data access module 1106 sends alerts and/or alarms regarding the exchange being insufficient. 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 cases, the data access module 1106 may request that the patient perform a full exchange.

In an example, an alert and/or reminder can be generated to indicate that the patient should select a different therapy program or make an adjustment to the therapy program from a plurality of prescribed therapy programs. In this example, the alarm or reminder rules may specify that the data access module 1106 compare the patient's blood pressure or weight to respective change thresholds while calculating and comparing the cumulative fluid value to the threshold. The cumulative fluid value may be determined from the individual fluid fill volumes and drain volumes, which are indicative of the fluid remaining in the patient's peritoneal cavity. If the blood pressure or weight and the accumulated fluid value (or trend) are outside of the acceptable range, the data access module 1106 generates an alert. The alert may indicate that the patient has accumulated fluid and that a treatment program with a longer drain duration (or shorter fill duration) should be selected (or that the treatment program should be adjusted to provide a longer drain duration or shorter fill duration). The data access module 1106 sends an alert for display on the personal mobile communication device 200 a. The patient may respond via the application 1002 or text message causing the clinician server 200b to make appropriate changes to the patient's prescription or treatment program.

In some embodiments, the alert and/or reminder may specify a condition under which the patient is to be prompted for additional information. In these embodiments, the data access module 1106 uses the therapy information from the home therapy apparatus 90 as a basis for determining whether the patient is to provide medical information via the personal mobile communication device 200 a. In an example, the data acquisition module 1106 can access alert and/or reminder rules that specify conditions under which a prompt or text message is sent to the patient's personal mobile communication device 200a to prompt for additional weight or blood pressure measurements. For example, if the blood pressure value (or trend) exceeds a predetermined threshold, an alarm or reminder may specify that a prompt is required for a new blood pressure measurement. In other examples, if the accumulated fluid values or UF removed values (or trends) are outside of acceptable ranges, an alarm or reminder may specify that a prompt is needed for a new blood pressure measurement. In response, the data access module 1106 sends a text message or notification via the application 1002 to cause 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) prompting the patient to enter blood pressure information. If the additional data received from the personal mobile communication device 200a is not within an acceptable range, the data access module 1106 can raise the reminder to an alarm that is communicated to the clinician device 152 and/or the personal mobile communication device 200 a. Thus, the data access module 1106 is configured to operate rules that determine critical patient conditions that seek additional information from the patient before determining whether further attention or action is required by the clinician or patient.

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

In another example, the data access module 1106 can include one or more rules that specify that an alert be generated in response to therapy information being out of range. For example, a large difference between the fluid fill volume and the drain volume may indicate a leak in the dialysis tubing or the connection to the patient. In response, the data access module 1106 sends an alert to the patient prompting the patient to verify the fluid connection. The patient may provide a response indicating whether a leak is detected. In response, the data access module 1106 determines whether the leak is corrected or whether the pipeline should be replaced in a subsequent processing cycle (or basic sequence). The data access module 1106 may determine cartridge, or like consumable issues based on the therapy and/or medical information. For example, a small amount of UF removed may prompt the data access module 1106 to send a reminder to the patient to verify the concentration of dialysate and/or concentrate being connected to the home therapy apparatus 90.

D. Treatment control Module embodiments

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

The prescriptions and related programs are stored in electronic prescriptions in the clinician database 1010. In some embodiments, the prescription may be stored in a patient's medical record. The home therapy device 90 is programmed with one or more prescriptions. The programming may be performed locally via the clinician or patient, or may be performed remotely from the clinician server 200 b. 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 example therapy control module 1110 is configured to operate in conjunction with an application 1002 on the personal mobile communication device 200a and/or an application on the clinician device 152 to enable the patient and/or clinician to select a different prescription program and/or prescription. Fig. 31 shows a diagram of a user interface 3100 for the application 1002 that enables a patient to select between three different programs: short program, long program, and weekend program. The patient may select a procedure based on their activity and/or situation. In some embodiments, the application 1002 may display an alert from the data access module 1106 that provides a recommendation to change the procedure based on the detected fluid accumulation, weight gain, or blood pressure rise.

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

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

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

In the case where the personal mobile communication device 200a does not include an application 1002, the therapy control module 1110 is configured to allow the prescription to be changed. For example, the therapy control module 1110 may host a website accessible by a Web browser on the personal mobile communication device 200 a. The website may include features similar to the user interface 3100 of fig. 31 to enable the patient to remotely select different programs and/or prescriptions.

Additionally or alternatively, the therapy control module 1110 is configured to enable therapy changes via text messages. In an example, the patient may send a message from the personal mobile communication device 200a that includes a text of "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 following each option. The patient may enter an identifier or code in the response message to select the desired procedure. In another example, the patient may send a message with text, for example, consisting of "long program" to cause the therapy control module 1110 to change the program to a long 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 200 a. Similar to the other modules 1102-1106 and module 1110 of fig. 11, the education module 1108 is configured to provide content/information based on the configuration of the personal mobile communication device 200 a. For example, if the application 1002 is installed, the education module 1108 is configured to select and provide educational materials through the application 1002. If the application is not installed, the education module 1108 is configured to provide educational materials via a website and/or text message. In the example of a text message, the education module 1108 may be configured to construct educational materials appropriate for the text message or to provide a link to educational materials hosted at the clinician database 1010 or by a third party server.

As described herein, 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 device 90. It may also be targeted as instructional material based on detected patient conditions (as determined by their medical history) and/or feedback regarding the patient's use of the application 1002 and/or the home therapy apparatus 90.

Further, as described herein, encouragement includes text, audio, video, or multimedia presentations intended to improve a patient's mood or assist a patient in adhering to a program. The incentive may also include a reward or badge. In some embodiments, the education module 1108 may be configured to provide encouragement based on the detected condition. In some cases, incentives may be provided in conjunction with alerts generated by the data access module 1106. In an example of encouragement, the patient may be provided different status levels based on adherence rate (e.g., "dialysis macros" for near perfect adherence).

Educational materials and/or encouragement may be stored in the clinician database 1010. Additionally, the education module 1108 may access third party material, such as from the national institutes of health or ClevelandThe material of (1). The education module 1108 may include a rule data structure that specifies conditions under which certain educational materials and/or encouragement are to be provided to the personal mobile communication device 200 a.

In an example, the data access module 1106 determines that the patient does not adhere to treatment. In addition to the data access module 1106 sending alerts, the education module 1108 may also suggest or provide video links regarding the importance of adherence. Fig. 32 illustrates an example user interface 3200 for an application 1002 that displays educational videos related to adherence provided by the educational module 1108. The example user interface 3200 also provides a list of recommended educational materials based on the detected patient condition. For example, after detecting from the medical record that the patient has hypertension or receives it as medical information, the education module 1108 is configured to recommend educational content regarding lowering blood pressure. Further, upon detecting that the patient does not yet have a prescription procedure changed, the education module 1108 determines that educational content explaining the procedure options should be recommended.

The example education module 1108 may also detect how the patient interacts with the application 1002 and recommend educational content. For example, the education module 1108 receives feedback from the application 1002 indicating that the patient made multiple attempts at filling out data fields of a user interface (e.g., user interface 14 of fig. 14) using the recorded images. In response, the education module 1108 may provide a notification via the application 1002 recommending the patient to view a course of information entry regarding the images of the usage record.

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

F. Auxiliary Module embodiments

The example assistance module 1112 of fig. 12 is configured to create a communication session between a patient and a clinician. In particular, the assistance module 1112 is configured to create a communication session between the clinician device 152 and the personal mobile communication device 200 a. The assistance 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 assistance module 1112 may access an option for selecting a video session, conference session, or Web messaging session for connecting the patient to the clinician through the application 1002. If the application 1002 is not installed, the supplementary module 1112 may be limited to options related to the native communication capabilities of the personal mobile communication device 200a, such as text messaging and audio calls.

In some embodiments, the patient may initiate a session. The application 1002 is configured to enable the patient to request contact with the clinician, including specifying a preferred communication method. Using the text feature of the application 1002, the patient may send a text message including the "help" text to the assistance module 1112 to begin the session. After the patient requests to begin the session, the assistance module 1112 is configured to identify available clinicians. In some embodiments, the assistance module 1112 may locate the record of the clinician associated with the patient and send a ping/solicitation message to their device. The response received from one of the devices 152 provides an indication that the clinician is available and willing to communicate with the patient. In some cases, the response may indicate the clinician's communication mode. In response to the received message, the assistance module 1112 starts the communication session. This may include establishing a Web call, messaging session, or audio call between the personal mobile communication device 200a and the clinician device 152. In some embodiments, in addition to broadcasting ping messages to a group of clinicians, the assistance module 1112 may send ping/solicitation messages to clinicians sequentially according to a predetermined order (e.g., first clinician, second clinician on duty in the same office, third clinician on duty in other offices, etc.). FIG. 33 shows a diagram of a user interface 3300 of an application 1002 that provides video sessions within a clinician. Video sessions enable patients to address their concerns with treatment. The video session also enables the clinician to view real-time settings for treatment or to assist the patient in setting up treatment.

In some embodiments, assistance module 1112 may determine to open the communication session, or recommend opening the communication session. The assistance module 1112 may provide recommendations in conjunction with the data access module 1106 that generate alerts and/or reminders. The assistance module 1112 may, upon detecting a condition for the reminder and/or alert, identify the clinician device 152 available to participate in the session and then initiate a call to the personal mobile communication device 200a to resolve the reminder and/or alert. In an example, the assistance module 1112 may attempt to create a communication session after detecting that the patient's blood pressure, weight, accumulated fluid, etc. is above a predetermined threshold or has significantly changed within a predetermined time period.

The example assistance module 1112 may determine the type of assistance being sought to identify the correct person to connect to. The supplementary module 1112 may be connected to information technology specialists and home treatment unit specialists in addition to the clinician. Prior to beginning the session, the application 1002 may prompt the patient to identify an assistance type (e.g., application assistance, machine assistance, clinical assistance, etc.). In other cases, the assistance module 1112 may determine the assistance type based on the context in which the session request was received. For example, after reviewing an educational training program for the home therapy apparatus 90, the assistance module 1112 determines that a subsequent assistance request is relevant to operating the home therapy apparatus 90. In another example, when the application 1002 is displaying a user interface regarding UF trends, the assistance module 1112 determines that the subsequent assistance request is for a clinical question.

The example assistance module 1112 may be configured to record a log of the communication session into a medical record of the patient. The assistance module 1112 may record the date/time of the communication session and an indication of how to initiate the session. The record may also include participants of the communication session and a record of the communication. For text messages, this may include a copy of the message. For audio or video, this may include a recording of the call or a transcription of the call.

III.Conclusion

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