BR112021002555A2 - medical fluid delivery system including a mobile platform for patient engagement and compliance with treatment - Google Patents

Abstract

MEDICAL FLUID DISTRIBUTION SYSTEM INCLUDING A MOBILE PLATFORM FOR PATIENT ENGAGEMENT AND COMPLIANCE WITH TREATMENT. The present invention relates to a patient platform for patient engagement and compliance with treatment. In one example, a processor is configured to obtain medical information from a patient for monitoring engagement and treatment compliance. To obtain the medical information, the processor causes a user interface to be displayed with fields to be filled with medical information. After receiving a selection of a data field, the processor provides an option to record medical information from an image. If the option is selected, the processor receives a recorded image of a medical device or a screen of a medical device, extracts the text from the image, allows a selection of at least a part of the text from the image, and writes the selected text from the image in the data field of the user interface as the medical information. The processor transmits medical information to a patient's medical record stored in a physician's database.

Description

Invention Patent Descriptive Report for "SYSTEM

MEDICAL FLUID DISTRIBUTION INCLUDING A

MOBILE PLATFORM FOR PATIENT ENGAGEMENT AND COMPLIANCE WITH TREATMENT". Background

[001] Engaging a patient outside of a medical setting for an extended period is currently a virtually impossible task. Similar to starting a gym membership or purchasing a treadmill, many patients typically start out strong. For example, at the outset, patients are readily engaged with a medical treatment (eg, a medical fluid delivery treatment) that is self-administered in patients' homes. For treatment, patients need to connect to a medical fluid dispensing machine (or containers that hold a treatment fluid for kidney failure) to cleanse their blood of a buildup of toxins. Part of the treatment may include tasks that patients need to perform, such as weighing, obtaining their blood pressure and/or recording information related to their treatment. This information recorded by patients is often reviewed by physicians to make sure treatment is progressing as prescribed. Physicians also review the recorded data to determine whether an adjustment to treatment is necessary.

[002] Over time, many patients become less enthusiastic about treatments as they lose the novelty and become just another chore. As can be imagined, patients are more likely to engage in more exciting, relaxing, or stimulating activities compared to self-administered medical treatment. As patients continue with treatments, they sometimes begin not to perform the additional tasks that accompany treatments. The omission of additional tasks and less enthusiasm for treatments present the potential for creating gaps in clinical supervision of ongoing treatment. As patients become less engaged with treatments, they begin to skip treatments or give up altogether, risking their health in the process. summary

[003] A medical fluid data transfer system, including a mobile platform, is described here. The medical fluid data transfer system is configured to enhance a patient's engagement and/or compliance with treatment through interactions provided through a patient's handheld device (e.g., a cell phone, a smartphone, a tablet computer , etc.). Specifically, the medical fluid data transfer system provides increased feedback and control for the patient (without feeling overwhelmed), which makes the patient feel as if they are in control of their own treatment rather than being following a doctor's instructions. For example, a mobile personal communication device of the medical fluid data transfer system may display treatment information and/or patient vital signs data. The mobile personal communication device can also allow a patient to switch between different treatments or prescribed programs without having to directly program a medical fluid dispensing machine. Patients who feel in control are more likely to remain engaged in their care.

[004] The illustrative medical fluid data transfer system also reduces the burden of collecting data on the patient by automating the process. For example, a mobile personal communication device allows a patient to capture treatment data or vital signs data for automatic transmission to a centralized physician database. Patients can record data directly on a mobile personal communication device, receive the data electronically from a connected machine, or record the data using a camera. The data is transmitted within the medical fluid data transfer system to a database that stores the data in a patient's medical record.

[005] Additionally, the Illustrative Medical Fluid Data Transfer System provides a gateway for physicians to allow a patient to communicate with the physician in real-time regarding any concerns or questions regarding a medical fluid delivery treatment. . In some embodiments, the medical fluid data transfer system also provides access to educational or training material for the patient. As such, the illustrative medical fluid data transfer system is configured to connect a patient to needed or requested assistance to remain engaged and/or compliant with a treatment.

[006] The medical fluid data transfer system and methodology of the present description are applicable, for example, to the delivery of fluid for plasmapheresis, hemodialysis ("HD"), hemofiltration ("HF"), hemodiafilttage ("HDF") ), and continuous renal replacement therapy ("CRRT") treatments. The medical fluid data transfer system described herein is also applicable to peritoneal dialysis ("PD"), intravenous drug delivery, and nutritional fluid delivery. These modalities may be referred to herein, collectively, or generally individually, as medical fluid delivery or treatment.

[007] The above modalities can be provided by a medical fluid dispensing machine that houses the components necessary to dispense medical fluid, such as one or more pumps, valves, heaters, if necessary, online medical fluid generation equipment, if necessary, sensors, such as any one, more, or all pressure sensors, conductivity sensors, temperature sensors, air detectors, blood leak detectors, and the like, user interfaces, and control units, which may employ one or more processors and memory to control the equipment described above. The medical fluid delivery machine may also include one or more filters, such as a dialysis or hemofiltration machine to clean the blood and/or an ultrafilter to purify water, dialysis fluid or other filter.

[008] The medical fluid dispensing machine and medical fluid data transfer system and methodology described here can be used with domestic machines. For example, the systems can be used with home HD, HF or HDF machines, which are operated at the patient's convenience. Such a home system is described in U.S. Patent No.

8,029,454 ("the '454 Patent"), issued October 4, 2011, entitled "High Convection Home Hemodialysis/Hemofiltration And Sorbent System", filed November 4, 2004, assigned to the assignees of this application. Other similar domestic schemes are described in US Patent No. 8,393,690 ("the '690 Patent"), issued March 12, 2013, entitled "Enclosure for a Portable Hemodialysis System", filed August 27, 2008. the entire contents of each of the above references are incorporated herein by reference and serve as a basis.

[009] As described in detail below, the medical fluid data transfer system and methodology of the present description can operate within a comprehensive platform system that can include many machines comprising many different types of devices, patients, physicians, doctors, service personnel, electronic medical records ("EMR") databases, a website, a resource planning system that handles data generated through patient-physician communications, and business intelligence. The medical fluid data transfer system and methodology of the present description operates continuously within the overall system and without contravening its rules and protocols.

[0010] In view of the description presented here and without limiting the description in any way, in a first aspect of the present description, which may be combined with any other aspect listed here, unless otherwise specified, a machine accessible device, having instructions stored therein that are configured, when executed, to cause a machine to populate patient medical records from a clinical system by operating a camera to record images, operating a display interface, operating a connection interface configured to connecting to a physician database, the physician database being configured to store the patient's medical records, and operating a processor to obtain the medical information. The processor is operated to obtain medical information by displaying, through the display interface, a user interface with fields to be filled with medical information, and after selecting a data field from the user interface, graphically providing, through of the display interface, a first option of recording medical information from an image and a second option of recording medical information through text recording. If the first option is selected, the processor receives an image recorded with the camera, the recorded image including a medical device or a screen of a medical device, extracts text from the image, allows a selection, through the display interface, of at least a part of the text from the image, and writes the selected text from the image into the data field of the user interface as medical information. If the second option is selected, the processor allows the recording of text from the data field, through the display interface, as medical information. The processor is also operated to obtain medical information, after a sent instruction has been received, by transmitting the medical information written in the data field to a patient's medical record stored in the physician's database.

[0011] In accordance with a second aspect of the present description, which may be used in combination with any other aspect listed here, unless stated otherwise, the machine accessible device further comprises instructions stored therein which are configured, when executed, to cause the machine to operate the processor to determine a data template for the extracted text in the image, process the extracted text using the data template to group the extracted text into fields, and allow a selection of at least one of the fields to write the selected text from the image into the data field of the user interface.

[0012] In accordance with a third aspect of the present description, which may be used in combination with any other aspect listed here, unless stated otherwise, the data template is configured to specify a context for the extracted text with respect to the text positions within the image.

[0013] In accordance with a fourth aspect of the present description, which may be used in combination with any other aspect listed here, unless stated otherwise, the machine accessible device further comprises instructions stored therein which are configured, when performed, to cause the machine to operate the processor to determine the data template based on at least one of: (i) a selection through the user interface of a type of medical device, (ii) the digitized information from an identifier located on the medical device, and (iii) a label within the extracted text, or (iv) a relative placement of the extracted text.

[0014] In accordance with a fifth aspect of the present description, which may be used in combination with any other aspect listed herein, unless otherwise noted, the identifier located on the medical device includes at least one of a rapid response code ( "QR"), a barcode, a serial number, or a hardware number located on a medical device housing or medical device display.

[0015] According to a sixth aspect of the present description, which may be used in combination with any other aspect listed herein, unless otherwise stated, the medical device includes at least one therapy machine for renal failure, a infusion, an oxygen sensor, a respiration monitor, a glucose meter, a blood pressure monitor, an ECG monitor, a weighing scale, and a heart rate monitor.

[0016] In accordance with a seventh aspect of the present description, which may be used in combination with any other aspect listed here, unless otherwise noted, the user interface data field is configured to receive at least one of the data blood pressure measurement, pulse data, weight data, glucose data, temperature data, renal failure manual exchange data, subjective data, or consumption data referring to a consumable item.

[0017] Pursuant to an eighth aspect of the present description, which may be used in combination with any other aspect listed here, unless otherwise noted, the consumable item includes at least one of a filter, a line set of blood, a dialysis material concentrate container, a blood anticoagulant container, a medication container, a disposable case, an adsorbent cartridge, and a water purification container.

[0018] According to a ninth aspect of the present description, which may be used in combination with any other aspect listed here, unless stated otherwise, the machine is a mobile personal communication apparatus.

[0019] Pursuant to a tenth aspect of the present description, which may be used in combination with any other aspect listed here, unless otherwise noted, a method of completing a patient's medical record from a clinical database, using recorded images, includes transmitting to a personal device a first message advising a patient to use a camera on the personal device to record a first image of a medical device, and receiving the first image from the personal device. The method also includes determining, from the first image, through a processor, the first medical information indicative of a type or model of the medical device, determining, through the processor, a data template and a second message associated with the type or model. of the medical device, and transmitting, through the processor, the second message to the personal device advising the patient to use the camera to record a second image of a screen of the medical device. The method further includes receiving, through the processor of the personal device, the second image, extracting, through the processor, text from the second image, and processing, through the processor, the extracted text using the data template to group the extracted text. in fields. The method further includes writing, through the processor, at least part of the text from at least one of the fields in the patient's medical record.

[0020] In accordance with an eleventh aspect of the present disclosure, which may be used in combination with any other aspect listed here, unless otherwise stated, the method further includes determining, through the processor, a correspondence between a of the fields to a record field in the patient's medical record, and to write, through the processor, at least the text part of the field, in the record field, in the patient's medical record.

[0021] In accordance with a twelfth aspect of the present description, which may be used in combination with any other aspect listed here, unless otherwise stated, the method further includes determining, through the processor, a treatment time from the patient's medical record, and transmit, through the processor, the first message before the treatment time.

[0022] In accordance with a thirteenth aspect of the present disclosure, which may be used in combination with any other aspect listed here, unless stated otherwise, the method further includes receiving, at the processor of the personal device, a message that indicates that a patient is about to start a treatment, and transmits, through the processor, the first message before the treatment starts.

[0023] In accordance with a fourteenth aspect of the present disclosure, which may be used in combination with any other aspect listed here, unless stated otherwise, the first image is received at the processor via a first text message or message Short Message Sending Service ("SMS") Service and the second message is received at the processor as a second text message or second SMS message.

[0024] In accordance with a fifteenth aspect of the present description, which may be used in combination with any other aspect listed here, unless stated otherwise, the method further includes converting, through the processor, at least part of the text of at least one of the fields in a Health Level 7 ("HL7") format, before writing to the patient's medical record.

[0025] In accordance with a sixteenth aspect of the present description, which may be used in combination with any other aspect listed here, unless stated otherwise, the method further includes comparing, through the processor, the at least part of the text of at least one of the fields with a predetermined range, and writing, through the processor, at least part of the text of at least one of the fields if at least part of the text of at least one of the fields is within the predetermined range .

[0026] In accordance with a seventeenth aspect of the present disclosure, which may be used in combination with any other aspect listed herein, unless otherwise noted, a system for transmitting information to a patient includes a home therapy machine for the patient. patient configured to transmit treatment information, and a physician database configured to store the medical record and a record file identifying the patient's home therapy machine and a personal device as registered devices and identifying whether the personal device has installed a application for viewing treatment information and medical information. The system also includes a physician server communicatively coupled to the physician database, home therapy machine, and personal device. The physician server is configured to store treatment information and medical information in the medical record, receive an indication that at least part of the treatment information and medical information should be displayed on the personal device, and determine, from the file registration, if the application was installed on the personal device. If the application has been installed, the doctor's server is configured to convert at least part of the treatment information and medical information into an application format for display within the application, and transmit at least part of the converted treatment information and the information medical device for personal device. If the application has not been installed, the doctor's server is configured to convert at least part of the treatment information and the medical information into text message or Short Message Service ("SMS") format, and transmit to at least part of the converted treatment information and medical information to the personal device via one or more text messages or SMS messages.

[0027] In accordance with an eighteenth aspect of the present description, which may be used in combination with any other aspect listed here, unless otherwise noted, the application format includes at least one of an Extensible Markup Language format ("XML") or a HyperText Markup Language ("HTML") format.

[0028] In accordance with a nineteenth aspect of the present description, which may be used in combination with any other aspect listed here, unless stated otherwise, indicating that at least part of the treatment information and the medical information must be displayed on the personal device must be displayed on the personal device includes at least one of a message from the application or a text/SMS message from the personal device.

[0029] In accordance with the twentieth aspect of the present description, which may be used in combination with any other aspect listed here, unless stated otherwise, the record file is included in the medical record.

[0030] In accordance with a twenty-first aspect of the present description, which may be used in combination with any other aspect listed here, unless otherwise noted, the home therapy machine is configured to store a prescription with two programs each one of the programs providing parameters for operating the home therapy machine to perform a treatment, and the physician's server is configured to receive a program message from the personal device indicative of a change to a second program from a first program, and transmitting a program instruction to the home therapy machine to switch to the second program from the first program.

[0031] In a twenty-second aspect of the present description, any one of the structure and functionality described with respect to Figures 1 to 33 may be combined with any other structure and functionality described with respect to Figures 1 to 33.

[0032] In view of the present description and aspects above, it is therefore an advantage of the present description if it provides an improved medical fluid delivery system.

[0033] It is another advantage of the present description if it provides the perfected lifestyle for the patient.

[0034] It is another additional advantage of the present disclosure if it provides improved efficiency for the physician or caregiver.

[0035] It is another further advantage of the present description if it provides the improved efficiency of the machine.

[0036] It is another additional advantage of the present disclosure if it provides improved patient compliance.

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

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

[0039] Furthermore, it is an advantage of the present description to reduce the waste of disposable sets and other sensitive auxiliary items due to discards, which often occur when machine timers expire.

[0040] The advantages discussed here can be found in one, or some, and perhaps not all of the modalities described here. Additional features and advantages are described here, and will be apparent from the Detailed Description and figures below. Brief Description of Figures

[0041] Figure 1 is a schematic view illustrating an embodiment for a medical fluid data transfer system incorporating the medical fluid dispensing machines of the present description, so that data can be transferred to and from such machines, according to an embodiment of the present description.

[0042] Figure 2 is a schematic illustration of an embodiment of a medical fluid delivery machine of the present description.

[0043] Figure 3 is a perspective view illustrating an arterial assembly for use with an embodiment of the medical fluid delivery machine of Figure 2, in accordance with an embodiment of the present description.

[0044] Figure 4 is a schematic view of an embodiment for a medical fluid delivery machine and data transfer system and method of the present description.

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

[0046] Fig. 6 is a schematic view of a third embodiment for a medical fluid delivery machine and data transfer system and method of the present description.

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

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

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

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

[0051] Figure 11 illustrates an illustrative diagram of operational modules of an application in a clinical server of the medical fluid data transfer system of figure 10, according to an embodiment of the present description.

[0052] Figure 12 illustrates an illustrative diagram of communications between a home therapy machine, a personal mobile communication device, and the clinical server of Figures 10 and 11, in accordance with an illustrative embodiment of the present description.

[0053] Fig. 13 illustrates an illustrative patient data structure stored in a clinical database of the medical fluid data transfer system of Fig. 10, in accordance with an illustrative embodiment of the present description.

[0054] Figures 14 and 15 illustrate illustrative diagrams of user interfaces of the application of figure 11, according to the illustrative modalities of the present description.

[0055] Fig. 16 is a schematic diagram of the personal mobile communication device of Figs. 10 and 11, according to an illustrative embodiment of the present description.

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

[0057] Figure 18 illustrates an illustrative diagram of a writing in the data fields of the user interface of figure 14, according to an illustrative embodiment of the present description.

[0058] Figure 19 is a flowchart of an illustrative procedure for recording medical information from an image using the mobile personal communication device application of figures and 11, according to an illustrative embodiment of the present description.

[0059] Figure 20 illustrates an example of a user interface that is displayed by the application on the mobile personal communication device of Figures 10 and 11, which allows a patient to provide a recorded image, according to an illustrative embodiment of the present description .

[0060] Figure 21 illustrates a schematic diagram of a patient's medical template used by the doctor's server of Figures 10 and 11 to fill in the data fields of a patient's medical record, according to an illustrative embodiment of the present description.

[0061] Figure 22 is a schematic diagram of a data acquisition module of the doctor server of figure 11, according to an illustrative embodiment of the present description.

[0062] Figures 23 and 24 are flowcharts of illustrative procedures to fill in the template of the medical device of figure 21 using the recorded images (and/or text messages received) by the mobile personal communication device of figures 10 and 11, according to with an illustrative embodiment of the present description.

[0063] Figure 25 illustrates a diagram of the doctor's server hosting a web site or file transfer site to receive medical information through an image from the mobile personal communication device of figures 10 and 11, according to an illustrative embodiment of the present description.

[0064] Figures 26 to 29 illustrate diagrams of the mobile personal communication device displaying medical information provided by the physician server of Figures 10 and 11, in accordance with illustrative embodiments of the present description.

[0065] Figure 30 illustrates a diagram of the mobile personal communication device of figures 10 and 11 requesting medical information from a patient, according to an illustrative embodiment of the present description.

[0066] Figure 31 illustrates a diagram of the mobile personal communication device of figures 10 and 11 providing a patient with the possibility of selecting a program for a medical treatment, according to an illustrative embodiment of the present description.

[0067] Figure 32 illustrates a diagram of the mobile personal communication device of Figures 10 and 11 providing educational content to a patient, in accordance with an illustrative embodiment of the present disclosure.

[0068] Fig. 33 illustrates a diagram of the mobile personal communication device of Figs. 10 and 11 providing a video chat session between a patient and a physician, in accordance with an illustrative embodiment of the present disclosure. Detailed Description

[0069] A medical fluid delivery system is described here. The illustrative medical fluid delivery system is configured to enhance a patient's engagement with a medical treatment, such as a medical fluid delivery treatment. The medical fluid delivery system is configured to provide a patient with greater transparency regarding their treatment and at least some control to direct their treatment, while providing resources to educate or otherwise assist the patient through the treatment process. . The illustrative medical fluid delivery system is configured to provide patient engagement regardless of a set of types or characteristics of treatment-related medical devices or patient mobile personal communication devices. Such a configuration allows the described medical fluid delivery system to be compatible with virtually any patient situation.

[0070] In some embodiments, the medical fluid delivery system includes a mobile personal communication device, a medical fluid delivery machine, and a physician server/database. The illustrative mobile personal communication device and medical fluid dispensing machine are located in a patient's home and/or located in a self-service medical facility. The physician server is communicatively coupled to the mobile personal communication device and/or the medical fluid delivery machine over a wide area network (ie, the Internet). The medical server is configured as a hub that allows the mobile personal communication device to provide features designed to engage a patient with a medical fluid delivery treatment.

[0071] As described here, the illustrative physician server receives medical fluid delivery data (e.g., treatment information) from the medical fluid delivery machine, which is stored in one or more patient records in a physician database. The physician server provides the mobile personal communication device with access to medical fluid distribution data to allow a patient to track the progress of treatment. In addition, a patient can use the mobile personal communication device to change a treatment program (or request a change to a treatment program). The request is stored through the clinician's server to verify the change as appropriate before being transmitted to the medical fluid dispensing machine.

[0072] The Illustrative Physician Server operates in conjunction with the mobile personal communication device to allow a patient to effortlessly provide medical information such as vital signs data, medical device data, etc. The mobile personal communication device is configured to allow a patient to manually record data, record images that include the data, and/or wirelessly receive data from connected medical devices such as weighing scales, blood pressure monitors, thermometers , glucose meters, etc. The data collected is stored in a patient's medical record. In some embodiments, the physician's server and/or mobile personal communication device may use templates to determine how received data should be automatically populated into a patient's medical record.

[0073] As described here, the mobile personal communication device may include a feature-rich smart device, such as a smartphone or tablet computer. The smart device can operate a specialized application (eg, an "app") that is defined by instructions stored in memory. Execution of stored instructions causes a smart device process to operate the application, which is configured to increase a patient's engagement with a medical treatment. In some cases, mobile personal communication device may include feature-light traditional mobile phone that contains considerably less processing power and resources compared to a smart device. The cellular device may operate using text messages and/or a specialized application (eg an App) that is defined by instructions stored in a memory. The app for the device with less features may have fewer features compared to the app for the smart device.

[0074] The description below is separated into two sections. A first section describes one embodiment of a medical fluid delivery system. A second section describes the features that allow the medical fluid delivery system to increase a patient's engagement and/or compliance with a medical treatment. |. Modality of the Medical Fluid Distribution System

[0075] The illustrative medical fluid delivery system includes one or more medical fluid delivery machines. An example of a medical fluid delivery machine is a kidney failure therapy machine. With regard to renal failure therapy machines, due to various causes, the patient's renal system may fail. Renal failure produces several physiological dysfunctions. It is no longer possible to balance water and minerals or to excrete the daily metabolic load. Toxic end products of nitrogen metabolism (urea, creatinine, uric acid, and others) can accumulate in blood or tissue.

[0076] Kidney failure and reduced kidney function have been treated with dialysis. Dialysis removes toxins and excess water from the body that the normally functioning kidneys would otherwise remove. Dialysis treatment to replace kidney function is critical for many people as the treatment saves lives.

[0077] One type of renal failure therapy is Hemodialysis ("HD"), which, in general, uses diffusion to remove waste products from a patient's blood. A diffusion gradient occurs through semipermeable dialysis equipment between blood and an electrolyte solution called dialysis solution or dialysis fluid to cause diffusion.

[0078] Hemofiltration ("HF") is an alternative renal replacement therapy that relies on a convective transport of toxins from the patient's blood. HF is accomplished by adding replacement fluid to the extracorporeal circuit during treatment (typically ten to ninety liters of such fluid). Replacement fluid and fluid accumulated by the patient between treatments is ultra-filtered during the course of HF treatment, providing a convective transport mechanism that is particularly beneficial in removing intermediate and large molecules (in hemodialysis there is a small amount of waste removed along with the fluid obtained between dialysis sessions, however, the solute drag from the removal of this ultra-filtrate is not sufficient to provide a convection space).

[0079] Hemodiaphyteus ("HDF") is a treatment modality that combines convection and diffusion spaces. HDF utilizes dialysis fluid flowing through a dialysis machine, similar to standard hemodialysis, to provide diffusion space. Furthermore, the replacement solution is supplied directly to the extracorporeal circuit, providing convection space.

[0080] Most HD treatments (HF, HDF) take place in centers. A trend toward home hemodialysis ("HHD") exists today in part due to the fact that HHD can be performed daily, offering therapeutic benefits over hemodialysis treatments performed at the center, which typically occur two or three times. per week. Studies have shown that frequent treatments remove more toxins and waste than a patient receiving less frequent but perhaps longer treatments. A patient who receives treatments more frequently does not experience as much of a downward cycle as a patient treated at the center who has accumulated two or three days of toxins prior to treatment. In certain areas, the nearest dialysis center may be miles from the patient's home, making door-to-door treatment time consume a large portion of the day. HHD can occur during the night or during the day while the patient is relaxing, working, or otherwise productive.

[0081] Another type of renal failure therapy is peritoneal dialysis, which infuses a dialysis solution, also called dialysis fluid, into a patient's peritoneal cavity through a catheter. Dialysis fluid comes in contact with the peritoneal membrane of the peritoneal cavity. Toxins and excess water pass through the patient's bloodstream, through the peritoneal membrane and into the dialysis fluid due to diffusion and osmosis, that is, an osmotic gradient occurs across the membrane. An osmotic agent in dialysis provides the osmotic gradient. Used or spent dialysis fluid is drained from the patient, removing waste, toxins and excess water from the patient. This cycle is repeated, for example, multiple times.

[0082] There are several types of peritoneal dialysis therapies, including continuous ambulatory peritoneal dialysis ("CAPD"), automated peritoneal dialysis ("APD"), and tidal flow dialysis and continuous flow peritoneal dialysis ("CFPD"). CAPD is a manual dialysis treatment. Here, the patient manually connects an implanted catheter to a drain to allow used or spent dialysis fluid to drain from the peritoneal cavity. The patient then connects the catheter to a bag of fresh dialysis fluid to infuse fresh dialysis fluid through the catheter and into the patient. The patient disconnects the catheter from the bag of new dialysis fluid and allows the dialysis fluid to remain within the peritoneal cavity, where transfer of waste, toxins and excess water takes place. After a period of stay, the patient repeats the manual dialysis procedure, for example, four times a day, each treatment lasting about an hour. Manual peritoneal dialysis requires a significant amount of time and effort from the patient, leaving a lot of room for improvement.

[0083] Automated peritoneal dialysis ("APD") is similar to CAPD in that dialysis treatment includes cycles of drain, supply, and stay. APD machines, however, perform the cycles automatically, typically while the patient sleeps. APD machines free up patients from having to perform treatment cycles manually and having to carry supplies throughout the day. APD machines are fluidly connected to an implanted catheter, a source or bag of fresh dialysis fluid, and a fluid drain. APD machines pump fresh dialysis fluid from a source of dialysis fluid, through the catheter and into the patient's peritoneal cavity. APD machines also allow dialysis fluid to remain within the cavity and transfer of waste, toxins and excess water to take place. The source may include multiple bags of sterile dialysis fluid.

[0084] APD machines pump used or spent dialysis solution from the peritoneal cavity, through the catheter, and into the drain. As with the manual process, multiple drain, fill and hold cycles occur during analysis. A "last fill" occurs at the end of the APD and remains in the patient's peritoneal cavity until the next treatment.

[0085] Any of the above modes performed by a machine can be run programmatically and can display an initialization procedure. For example, dialysis patients typically undergo treatment on a scheduled basis, such as every other day, daily, etc. Blood treatment machines typically require a certain amount of time before treatment to set up, for example, to run a disinfection procedure. Patients for the above modalities can lead busy lives and have projects to complete or tasks to perform on a scheduled day of treatment.

[0086] Much of the appeal of a home treatment to the patient revolves around the flexibility of the lifestyle provided, allowing the patient to perform treatment in their own home according to their own schedule. The home medical fluid dispensing machine may, however, include software timers that dictate and constrain the user or patient. A home hemodialysis system may, for example, require the patient to be very close to the home hemodialysis machine to start the pre-treatment, treatment and post-treatment sequences.

[0087] In one particular example, a home therapy machine can reuse certain components by disinfecting them between treatments. The machine may employ one or more disinfection timers that require the patient or caregiver to initiate treatment using the machine before the disinfection timer expires. Otherwise, the patient will need to wait until another disinfection procedure is completed before starting treatment. The home therapy machine in one modality communicates the treatment cut-off time through the machine's graphical user interface, which requires the patient to be close to the machine to access the start cut-off time and react accordingly.

[0088] It should be appreciated that the present description is applicable to any type of disinfection, such as hot water disinfection and chemical disinfection. In this regard, the present description is not limited to domestic therapy machines, for example, machines located in centers typically undergo chemical disinfection and may set an initial treatment deadline after such disinfection. Furthermore, the present description is not limited to initial cut-off times based on disinfection, but can also be applied to other start cut-off times, for example, those based on preparation completion. Additionally, the present description is not limited to initial cut-off times. For example, most machines allow the patient to temporarily stop treatment and disconnect from the machine to perform some necessary action away from the machine. For a blood treatment, the machine will typically rinse the blood back to the patient and may or may not circulate dialysis fluid for a period of time. In any case, the time for which the patient may remain temporarily disconnected from the machine is not unlimited, and it is contemplated that the present description also applies to the return time limit.

[0089] In one embodiment, the system of the present disclosure provides a software application ("app") that is installed on the patient's and/or caregiver's personal mobile communication device, e.g., the smartphone. The app is provided in a form through a middleware software application, an example of which is discussed in detail below. In an alternative embodiment, the software is configured to communicate with the patient's and/or caregiver's personal mobile communication device, e.g., smartphone, directly utilizing a text messaging feature via an application software application. middleware. In either case, the app or text message is structured in a modality to remind the patient of an impending deadline and to allow the patient and/or caregiver to monitor when a treatment needs to be started without connecting the patient to the machine.

[0090] Alternative, or additional, structuring of communication software is contemplated to automatically schedule reminders on the user's mobile communication device, for example, in the device's native task tracking features, such as a calendar application. Most smartphones come with a calendar that separates each day into segments, such as hours. The system software and methodology of the present description can be programmed to access the smartphone calendars of patients and/or authorized healthcare professionals and fill in the proper time segments of the proper day with proper information, for example, that the machine should start or end disinfection within that time segment.

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

[0092] It is contemplated that the software and system methodology of the present description disable communication between the patient and/or caregiver and the machine whenever the machine is in a "patient connected" software state. For example, if a doctor tries to send a command to a machine that is currently treating a patient, the command may be intercepted by the middleware software application, so the command is not transferred to the machine. The middleware software application can then communicate back to the physician that the machine is busy and does not support communication.

[0093] The examples described herein are applicable to any medical fluid delivery system that delivers a medical fluid, such as blood, dialysis fluid, replacement fluid, or intravenous ("IV") drug. The examples are particularly well suited for therapies of renal failure, such as all forms of hemodialysis ("HD"), hemofiltration ("HF"), hemodiafiltration ("HDF"), continuous renal replacement therapies ("CRRT") and peritoneal dialysis ("PD"), collectively, or generally individually, referred to herein as renal failure therapy. The medical fluid delivery machines may alternatively be a drug delivery or nutritional fluid delivery device, such as a large volume peristaltic pump or syringe pump. The machines described here can be used in home settings. For example, a machine operating with the data transfer regime of the present disclosure may be employed with a home HD machine, which may, for example, run overnight while the patient is sleeping. The medical fluid data transfer system and methodology of the present disclosure may alternatively be used to assist physicians or nurses in hospitals and/or clinics.

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

[0095] While a single medical fluid dispensing 90 is illustrated as communicating with a connectivity server 118, the system 10 oversees the operation of a plurality of medical fluid dispensing systems and machines, of the same or different types listed above . For example, there may be an M number of hemodialysis machines 90, an N number of hemofiltration machines 90, an O number of CRRT machines 90, a P number of peritoneal dialysis machines 90, a Q number of home delivery machines of drugs 90, and a number R of nutritional or drug dispensing machines 90 connected to server 118 and operating with system 10. The numbers from M to R can be the same or different, and can be zero, one or more than a. In Figure 1, the medical fluid dispensing machine 90 is illustrated as a home therapy machine 90 (the residence indicated by the dashed lines).

[0096] The home therapy machine 90 may receive at its front end purified water from a water treatment device 60 as discussed above. The water treatment device 60 connects to the home therapy machine 90 via an Ethernet cable in one mode. Home therapy machines 90 in the illustrated embodiment operate with devices other than the water treatment device 60, such as a blood pressure monitor 104, a weighing scale, e.g. a wireless weighing scale 106, and an interface. such as a wireless tablet-type user interface 122. Home therapy machine 90 connects to server 118 wirelessly in one mode via a modem 102. Each of these components can (but need not) be located within the patient's home, as demarcated by the dashed lines in Figure 1. Any one, or more, or all components 60, 104, 106, and 122 can communicate wired or wirelessly with the home therapy machine 90. Wireless communication can be via Bluetooth"",

WiFitv, ZigbeeG, Z-WaveG, Wireless Universal Serial Bus ("USB"), 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 machine 90 via wired communication.

[0097] Connectivity server 118 communicates with medical fluid delivery machine 90 through a medical device system center 120. System center 120 allows data and information regarding each home therapy machine 90 and its peripherals travel back and forth through the connectivity server 118 between the machines 90 and the other clients connected to the server 118. In the illustrated embodiment, the system center 120 is connected to a service portal 130, to a enterprise resource planning 140, a network portal 150, a business intelligence portal 160, a HIPAA compliant database 124, a product development team 128 and maintained electronic medical records databases , for example, in clinics or hospitals 126a to 126n.

[0098] Electronic medical records ("EMR") databases at clinics or hospitals 126a to 126n store electronic information about patients. System center 120 may send data collected from machine files 90 to hospital or clinic databases 126a to 126n to merge or supplement that patient's medical records. Databases at clinics or hospitals 126a to 126n may contain patient-specific prescriptions and treatment data, and therefore access to such databases may be highly restricted. The enterprise resource planning system 140 obtains and compiles the data generated by accessing the patient and physician website, such as claims, billing information, and lifecycle management information. The web portal 150 allows patients and clinics 152a to 152n that are treating patients to access a web site publicly available to users of the medical fluid dispensing machines 90. The business intelligence portal 160 collects data from the system center 120 and provides data for marketing 162, research and development 164, and drug quality/surveillance 166.

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

[00100] In one embodiment, the home therapy machine 90 performs a home treatment, such as home hemodialysis, on a patient at the patient's home, and then reports the results of that treatment to the physicians, doctors, and nurses who are responsible for the treatment. management of the health and well-being of that patient.

[00101] Home therapy machines 90 in one embodiment write the files using, for example, a Linux'"" operating system. The files document 90 pertinent home therapy machine data, including peripheral device data. Files can include any one or more of Extensible Markup Language ("XML"), comma-separated values ("CSV"), or text files. The files are placed in a software file server box of the home therapy machine 90. It is also contemplated that the data is stored on a peripheral device, e.g., water treatment device 60, which is not sent to the machine 90 Such data may otherwise be obtained through a wired or wireless connection to the peripheral device or downloaded through other data connections or storage media. For example, a maintenance worker can access additional data via a laptop connected to the water treatment device 60 or wireless weighing scale 106, for example via an Ethernet connection. Or, additional data may be retrieved remotely from the peripheral devices, with the home therapy machine 90 serving as the data transfer link between the peripheral device and authorized clients of the medical fluid data transfer system.

[00102] In one embodiment, the home therapy machine 90, for example via the Internet, uses a connectivity service to transfer data between the modem 102 and the system center 120. Here, a dedicated line may be provided on the home therapy machine 90 to connectivity server 118 via modem 102. Home therapy machine 90 in one embodiment accesses the Internet using a separate modem, e.g. 3G, 4G or 5G 102. modem 102 may use an Internet Service Provider ("ISP"), such as Vodafone"". In one implementation, a connectivity agent 114, developed by a connectivity service provider (e.g., connectivity service provider 118) is installed on home therapy machine 90 and run on ACPU 50 of the machine. A suitable connectivity service is provided by Axeda”“Y, which provides a securely managed connection 116 between the medical devices and the connectivity server 118.

[00103] Connectivity Agent 114 allows Home Therapy Machine 90 to connect to Connectivity Server 118 and transfer data to and from Connectivity Server 118. Connectivity Server operating through Agent 114 and Server 118 ensures that the connection with the 90 machine is secure, ensures that data passes correctly through the 920 machine's firewalls, checks if a data or system break has occurred, and ensures that the connectivity server 118 is communicating with the correct home therapy machine 90.

[00104] In one embodiment, home therapy machine 90 can only connect to connectivity server 118 when connectivity agent 114 is powered on or activated. During treatment and post-treatment disinfection, while the machine 90 and its peripherals are running, the connectivity agent 114 is turned off if a modality, which prevents the home therapy machine 90 from communicating with any entity and sending or receiving the data during treatment and disinfection, or when the machine 90 is on or running. When the home therapy machine 90 is idle, for example after completion of treatment and post disinfection, the ACPU 50 turns on connectivity agent 114 in one mode. In one embodiment, connectivity agent 114 is off during treatment and possibly pretreatment. After treatment, connectivity agent 114 retrieves files from home therapy machine 90 and transfers the data to connectivity server 118 using the connectivity service. The connectivity service directs data packets to their proper destination, but in one embodiment does not modify, access, or encrypt the data.

[00105] In the medical fluid data transfer system 10 of Figure 1, the connectivity service through the connectivity server 118 can communicate the data to various locations through a system hub 120, such as a service portal 130, clinics or hospitals 126a to 126n, and a network gateway 140. Connectivity server 118 allows maintenance personnel 132a to 132n and/or physicians to track and retrieve various assets over the network, such as suitable home therapy machines 90 and modem 3G, 4G or 5G 102, and its associated information, including serial machine or modem numbers. Connectivity server 118 may also be used to receive and deliver firmware updates, approved by a director of maintenance personnel 134 and obtained remotely through service portal 130, to authorized home therapy machines 90 and associated peripherals, such as water treatment devices 60. A. Illustrative Medical Fluid Dispensing Machine

[00106] Referring now to Figure 2, an example of a schematic HD flow for the medical fluid dispensing machine 90 is illustrated. Since the HD system of Figure 2 is relatively complicated, Figure 2 and its discussion also provide support for any of the renal failure therapy modalities discussed above and for an IV machine, drug delivery, or nutritional fluid delivery. Generally, the medical fluid delivery machine 90 is illustrated having a simplified version of a dialysis fluid or process fluid delivery circuit. The blood circuit is also simplified, but not to the degree of simplification of the dialysis fluid circuit. It should be appreciated that the circuitry has been simplified to make the description of the present description easier and that the systems, if implemented, have additional structure and functionality, as found in the publications incorporated by reference above.

[00107] The medical fluid dispensing machine 90 of Figure 2 includes a blood circuit 20. The blood circuit 20 draws blood from and returns blood to patient 12. Blood is drawn from patient 12 through a line arterial line 14, and is returned to the patient via a venous line 16. The arterial line 14 includes an arterial line connector 14a that connects to an arterial needle 14b, which is in blood drawing communication with the patient 12. venous line 16 includes a venous line connector 16a which connects to a venous needle 16b which is in blood return communication with the patient. Arterial and venous lines 14 and 16 also include line clamps 18a and 18v, which can be fail-safe, spring-loaded mechanical narrowing clamps. Line fasteners 18a and 18v are automatically closed in an emergency situation in one mode.

[00108] 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 search for air in arterial and venous lines 14 and 16, respectively. If air is detected by one of the 22a and 22v air detectors, system 10 closes the 18a and 18v line clamps, pauses the blood and dialysis fluid pumps, and instructs the patient to remove the air so that treatment can be resumed.

[00109] “A blood pump 30 is located in the arterial line 14 in the illustrated embodiment. In the illustrated embodiment, the blood pump includes a first blood pump capsule 30a and a second blood pump capsule 30b. The blood pump capsule 30a operates with an inlet valve 32i and an outlet valve 320. The blood pump capsule 30b operates with an inlet valve 34i and an outlet valve 340. In one embodiment, the pump capsules blood vessels 30a and 30b are each blood receptacles which include a hard, e.g. spherical, outer shell with a flexible diaphragm located within the shell forming a diaphragm pump. One side of each diaphragm receives blood, while the other side of each diaphragm is operated by negative and positive air pressure. Blood pump 30 is alternatively a peristaltic pump operating with arterial line 14 or multiple peristaltic pumps operating with arterial line 14 and venous line 16.

[00110] A heparin bottle 24 and heparin pump 26 are located between the blood pump 30 and the blood filter 40 (eg, the dialysis machine) in the illustrated embodiment. The heparin pump 26 may be a pneumatic pump or a syringe pump (e.g., stepper motor driven syringe pump). Supplying heparin upstream of the blood filter 40 helps prevent clots from forming in the filter membranes.

[00111] A primary control processor ("'ACPU") or control unit 50 includes one or more processors and memories. Control unit 50 receives air detection signals from air detectors 22a and 22v (and other sensors in system 10, such as temperature sensors, blood leak detectors, conductivity sensors, pressure sensors, and disconnect transducers. access ports 86, 88), and controls components such as line clamps 18a and 18v, blood pump 30, heparin pump 26, dialysis fluid pumps 64 and 96, and valves 32i, 320, 34i, 340, 68i, 680, 98 and

980. Blood leaving blood filter 40 via venous line 16 flows through an air trap 28. Air trap 28 removes air from the blood before dialyzed blood is returned to patient 12 via venous line 16.

[00112] With the hemodialysis version of the medical fluid dispensing machine 90 of Figure 2, dialysis fluid is pumped along the outside of the blood filter membranes 40, while blood is pumped through the inside of the filter membranes of blood. Dialysis fluid is prepared starting with purifying the water through a water purification unit 60. A suitable water purification unit is disclosed in US Patent Publication No. 2011/0197971 entitled "Water Purification System and Method" , filed April 25, 2011, the entirety of which is incorporated herein by reference and serving as a basis. In one embodiment, the water purification unit includes filters and other structures for purifying tap water (e.g., removing pathogens and ions such as chlorine) so that the water is at one of the implementations below 0.03 endotoxin units/ml ("EU/ml"), and below 0.1 colony forming units/ml ("CFU/ml"). The water purification unit 60 may be provided in a separate housing from the hemodialysis machine housing or chassis 90, which includes the blood circuit 20 and the dialysis fluid circuit 70.

[00113] Dialysis fluid circuit 70 is again highly simplified in Figure 2 for ease of illustration. The dialysis fluid circuit 70, in fact, may include all the relevant structure and functionality presented in the publications incorporated by reference above. Certain features of the dialysis fluid circuit 70 are illustrated in Figure 2. In the illustrated embodiment, the dialysis fluid circuit 70 includes a filter dialysis fluid pump towards the blood 64. The pump 64 is, in one embodiment, configured the same as blood pump 30. Pump 64, like pump 30, includes a pair of pump capsules 66, each having inlet valves 68i and outlet valves 680 which, again, can be configured into a spherical shape. The two pump pods, as with the blood pump 30, are operated alternately so that one pump pod is being filled with HD dialysis fluid while the other pump pod is expelling HD dialysis fluid.

[00114] Pump 64 is a filter dialysis fluid pump in the blood direction. There is another double capsule pump chamber 96 operating with valves 98i and 980 located in drain line 82 to push used dialysis fluid to the drain. There is a third capsule pump (not shown) for pumping purified pump water through a bicarbonate cartridge 72. There is a fourth capsule pump (not shown) used to pump acid from the acid container 74 into the line. 62. The third and fourth pumps, the concentrate pumps, can be single-capsule pumps as continuous pumping is not as important in the mixing line 62 due to a storage dialysis fluid tank (not shown) between the mixing line 62 and the filter dialysis fluid pump towards the blood 64 in one embodiment.

[00115] “A fifth capsule pump (not shown), provided in drain line 82, is used to remove a known amount of ultrafiltration ("UF") when HD therapy is provided. The system monitors the UF pump to track and know how much ultrafiltrate has been removed from the patient. System 10 ensures that the required amount of ultra-filtrate is removed from the patient by the end of the treatment.

[00116] Each of the pumps described above may alternatively be a peristaltic pump operating with a pumping tube. If that is the case, the system valves can still be pneumatically actuated in accordance with the features of the present description.

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

[00118] —Figure 2 also illustrates that dialysis fluid is pumped along a fresh dialysis fluid line 76, through a heater 78 and an ultrafilter 80, before reaching the blood filter 40, after which the fluid used dialysis fluid is pumped to drain through drain line 82. Heater 78 heats dialysis fluid to body temperature or about 37°C. Ultrafilter 80 further cleans and purifies dialysis fluid before reaching the blood filter 40, filtering foreign matter and/or contaminants introduced, for example, through the bicarbonate cartridge 72 or acid container 74 from the dialysis fluid.

[00119] The dialysis fluid circuit 70 also includes a sample port 84 in the illustrated embodiment. The dialysis fluid circuit 70 will further include a blood leak detector (not shown, but used to detect if a fiber of the blood filter 40 has been torn) and other components not shown, such as balance chambers, various valves of dialysis fluid, and a dialysis fluid holding tank, all described and illustrated in detail in the publications incorporated by reference above.

[00120] “In the illustrated embodiment, the medical fluid dispensing machine 90 is an online pass-through system that pumps dialysis fluid through the blood filter once and then pumps used dialysis fluid into the drain. Both the blood circuit 20 and the dialysis fluid circuit 70 can be disinfected with hot water after each treatment so that the blood circuit 20 and the dialysis fluid circuit 70 can be reused. In one implementation, the blood circuit 20, including the blood filter 40, is hot water disinfected and reused daily for about a month, while the dialysis fluid circuit 70 is hot water disinfected and reused for about six months. .

[00121] In alternative embodiments, for CRRT, for example, multiple bags of sterile or infused dialysis fluid are pooled and used one after the other. In such a case, the emptied supply bags can serve as bags of drained or spent fluid.

[00122] The medical fluid dispensing machine 90 includes an enclosure as indicated by the dashed line in Figure 2. The enclosure of the machine 90 varies depending on the type of treatment, whether the treatment takes place at the center or is a home treatment, and whether the dialysis/infused fluid supply is of a batch type (eg bagged) or online.

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

[00124] In figures 2 and 3, any of the pumps 26, 30 (30a and 30b), 64, 96 (and other pumps not shown) and any of the valves, such as valves 32i, 320, 34i, 340, 68i, 680, 98i and 980 can be pneumatically actuated. In one embodiment, each of the pumps and valves has a fluid side and an air side, separated by a flexible membrane. Negative pneumatic pressure can be applied to the air side of the membrane to draw fluid into a pump chamber or to open a valve (or the pump or valve can be opened by venting the positive shut-off pressure to atmosphere and allowing fluid pressure opens). Positive pneumatic pressure is applied to the air side of the membrane to expel fluid from a pump chamber or to close a valve. B. Illustrative Medical Fluid Distribution System Connectivity Modalities

[00125] Referring now to Figure 4, a system 110a of the present description is illustrated. System 110a in the illustrated embodiment operates with system 10 described above, including connectivity server 118, system hub 120, service gateway 130, enterprise resource planning system 140, network gateway 150, and business intelligence portal 160, which are illustrated in Figure 4 as part of a cloud environment. Connectivity server 118, system center 120, service portal 130, enterprise resource planning system 140, network portal 150, and business intelligence portal 160 can each be part of an environment cloud or may be located on one or more dedicated servers.

[00126] “Other components of system 10, not illustrated in Figure 4, may also be part of system 110a. For example, the medical fluid dispensing machines 90a and 90b may reside separately in the patient's residences 12a and 12b (which are illustrated as being outside the residence). Alternatively, medical fluid dispensing machines 90a and 90b may reside in the same clinic 126a to 126n or in different clinics 126a to 126n. Doctors 112a and 112b may remain inside or outside the clinics.

[00127] Medical fluid dispensing machines 90a and 90b are connected to connectivity server 118 via securely managed connections 116 as described above. To do this, machines 90a and 90b connect to the Internet 52, for example via the modems 102 discussed above. System hub 120 in one embodiment stores middleware software that is accessible by mobile communication devices 200a and 200b (referred to collectively herein as devices 200 or generally individually as device 200). Mobile communication devices 200a and 200b can be smartphones, for example, running on — operating — systems — Android'?y, jOS'y, Windows Phone”"", BlackBerry""Y, Sailfish OS'TY, Tizen'y or Ubuntu Touch". Mobile communication devices 200a and 200b may belong to patients 12a and 12b, respectively, and/or physicians 112a and 112b, respectively. Mobile communication devices 200a and 200b, as illustrated in Figure 4, are also connected to the Internet 52.

[00128] In one embodiment, mobile communication devices 200a and 200b download application software ("app") from the middleware software stored at the center of system 120 through its Internet connection 52. The app is updated whenever there is a change in the state of the corresponding machine 90a or 90b. For example, the medical fluid dispensing machine 90a may have just completed its automated automated testing routine and is ready to run a disinfection procedure. Machine 90a can generate code that identifies this state and sends the same middleware software pattern stored in the system center

120. The middleware software then translates the code into a message, for example using a lookup table such as "self test completed, ready for disinfection" and causes the app to be downloaded to the mobile communication device 200a of the patient

12a or clinician 112a displays the message. The app can be programmed to provide a visual identifier along with the message, such as an icon that is associated with the particular state in which the machine 90a resides. The app 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, which prompts patient 12a or physician 112a to view the app and see machine state change 90.

[00129] In another example, the medical fluid dispensing machine 90b may have been pre-programmed to start treatment at 3:00 pm. The 90b medical fluid dispensing machine may need three hours to perform the self test and disinfection. Patient 12a or physician 112a therefore needs to be at machine 90b around noon to begin pretreatment. In one embodiment, the patient 12a or physician 112a makes a setting on the machine 90b as to how long before the three hour set-up time the patient 12a or physician 112a should be notified or alerted, for example, two hours. So in this example, machine 90b can generate code at 10:00 and send the code to the middleware software stored in the center of system 120. The middleware software then translates the code into a message, for example using a look-up table, such as, "treatment preparation needs to start within two hours" and causes the app downloaded to the patient 12b or physician 112b's mobile communication device 200b to display the message. The app can be reprogrammed to provide a visual identifier along with the message, such as a countdown timer that counts down from one hundred and twenty minutes until a timer expires at zero. The app can also provide any one or more of an audio alert, such as a "ding" sound, and/or tactile feedback at pre-programmed intervals during the countdown period, for example, one hour and thirty minutes.

[00130] In addition to, or alternatively, the provision of the app on the user communication device 200b, it is contemplated for the middleware software at the center of the system 120 to convert the machine code 90b into a message that is housed in the monitoring facility 200 device's native task file, such as its calendar application. Most smartphone devices 200, for example, come with a calendar that separates each day into time segments, such as hours. Here, the message converted by the middleware software of the system center 120 can be programmed to access the calendar of the authorized communication device 200b and fill the proper time segment of the proper day with the proper information. In the example above, for the proper day, the native calendar software application will have its 10:0:00 time partition populated with a message such as "treatment preparation needs to start in two hours". An audible and/or tactile feedback signal can be provided to notify patient 12 or physician 112 of the calendar entry.

[00131] It should be appreciated that machines 90a and 90b, the middleware software on central server 120, and communication devices 200a and 200b can be programmed and operated as described above to deliver any desired message to patients 12a, 12b and/or physicians 112a, 112b and are not limited to the messages described herein. For example, patients 12a, 12b and/or physicians 112a, 112b may similarly be informed, at the end of disinfection with a countdown timer, that treatment needs to start within the countdown time to avoid the need to of re-disinfecting the machine 90a, 90b.

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

[00133] The hub of system 120 in one embodiment, stores middleware software that can be accessed by mobile communication device 200 (illustrated as a single device for ease, but multiple devices 200 can be similarly connected to system 110b) . The mobile communication devices 200 in Figure 5 include all the structure, functionality and alternatives described for the devices 200a and 200b illustrated in Figure 4, including being connected to the Internet 52. In Figure 5, the mobile communication device 200 can, but does not, need, download a software application ("app") of the middleware software stored in the system center 120 through its Internet connection 52. The app can be operated exactly as described above with respect to Figure 4, including the software of middleware by converting an encoded message from machine 90 into a format presentable in the app. Alternatively or additionally, middleware software stored at the center of system 120 may be able to convert machine code 90 into a message that is housed in the native task monitoring facility of communication device 200, such as its calendar application, in any of the ways described in Figure 4.

[00134] —Alternatively, or additionally, system 110b includes a cellular network 210 that interfaces between middleware software, e.g., stored at the center of system 120, and mobile communication device 200. Cellular network 210 may include a network of cell phone towers operating using radio waves and/or employing a satellite. Communication protocols suitable for use with the cellular network 210 of system 110b may be long-band protocols, such as (i) the "interoperability — worldwide! for microwave access" ("WiMAX") protocol; and (ii) the "Global System for Mobile Communications" ("GSM") protocol, which is a long-range, broad-spectrum wireless protocol that enables data communication with the 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 a protocol that is part of the 802.11 standard of the Institute of Electrical and Electronics Engineers. ("IEEE"), such as (i) IEEE 802.11a, (ii) IEXE 802.11b, (iii) WEE 802.11g, or (iv) 802.11n. Other suitable cellular technologies may include CDMA, AMPS (analog), General Packet Radio Service ("GPRS"), cimaOne, CDMAZ000, Enhanced Evolution Data ("EV-DO"), Enhanced Data Rates for GSM Evolution (" EDGE"), Universal Mobile Telecommunications System ("UMTS"), Digitalis Enhanced Wireless Telecommunications ("DECT"), AMPS

Digital ("IS-136/TDMA"), and Enhanced Integrated Digital Network ("DEN").

[00135] Mobile communication devices 200 communicate with cellular network 210 in any of the ways known to those skilled in the art, for example, via Short Message Sending Service ("SMS") or Sending Service protocols. of Multimedia Messaging ("MMS"). Middleware software at the heart of system 120 can communicate with cellular network 210 in a variety of ways. In one example, the telephone numbers and operators of users 12, 112 (any or all of patient 12, the patient's home care partner, patient 112's doctor) are linked, for example, through a table of query in the middleware software, to a specific machine 90. When a message/code from a specific machine 90 is received by the middleware, the middleware software can be programmed to send an email to [user phone number] OQ [ operator].net. For example, if patient 001's phone number is (555) 555-5555 and patient 001's operator is AT&T'Y, when patient 001's machine 90 sends a message to system center 120's middleware software, upon receipt, middleware software 120 is programmed to relay an email to 5555555555(Qatt.net, which is received by mobile communication device 001 of patient 200 as a text message. Those skilled in the art will understand that there are multiple web sites aimed at informing how to send an email to a text message, highlighting the details required by the different operators.

[00136] The middleware software stores each of the phone numbers of each of the mobile communication devices 200 and matches each of those numbers with a machine 90. When an event code is sent from a machine 90 to the software of middleware as described above, the middleware software locates the telephone number of the mobile communication device 200 associated with that machine, converts the code into a suitable message, for example using a lookup table as described above, and sends the message converted to the phone number called again. It is contemplated that multiple communication devices 200 may be associated with the same medical fluid dispensing machine 90. For example, at any of clinics 126a to 126n, multiple telephone numbers of doctors, nurses and/or physicians may be associated with the same machine.

90. In a home environment, telephone numbers for patient 12 and their physician and/or caregiver assistant may be associated with the same machine 90.

[00137] Likewise, the phone number for a mobile communication device 200 can be associated with multiple medical fluid dispensing machines 90. For example, in any of clinics 126a to 126n, a single nurse can monitor multiple machines 90. If an event occurs to any of these machines during the nurse's shift, the nurse can be notified via a cellular message sent to the nurse's mobile communication device 200. This situation is described in detail below with respect to the figures. from 7 to 9.

[00138] Cellular messages may carry information regarding any of the same events discussed above for the software app and calendar update modes of filling the mobile communication devices 200 with information. For example, the medical fluid dispensing machine 90 may have just completed its automated self-test routine and is now ready to run a disinfection procedure. Machine 90 can generate code identifying its state and send it to middleware software stored at the center of system 120. The middleware software then translates the code into a message, for example using a lookup table such as as "self test completed, ready for disinfection" and causes the cellular exit routine discussed above, for example, to send a text message to the mobile communication device 200 of the patient 12 or physician 112 to display the message. In an alternative embodiment, a code is not required and the machine 90 instead sends an actual text string, which the middleware software sends to the mobile communication device 200 as a text message via the cellular output routine. discussed above, for example. As is known, the receipt of the text message on the communication device 200 may be accompanied by an audio, for example, a "ding" sound, and/or a tactile alert, such as a vibration, which alerts the patient 12 or doctor 112 to view the message.

[00139] In another example, the medical fluid dispensing machine 90 may have been pre-programmed to start treatment at 3:00 pm. The medical fluid dispensing machine 90 may again require three hours to perform the self test and disinfection. Patient 12 or doctor 112 therefore needs to be near machine 90 around noon to start pretreatment. In one embodiment, the patient 12 or physician 112 performs a setting on the machine 90 of how long, prior to the three hour preparation period, that patient 12 or physician 112 should be notified or alerted, e.g., two hours. Here, machine 90 generates code at 10:00 am and sends the code to the middleware software stored at the center of system 120. The middleware software then translates the code into a message, for example using a table query, such as "treatment preparation needs to start within two hours" and causes the cell phone exit routine discussed above, for example, to send a text message to the patient's mobile communication device 200 12 or clinician 112, display the message, for example, along with an audible alert, such as a "ding" sound, and/or a tactile alert, such as a vibration, which warns the patient 12 or clinician 112 to view the notification.

[00140] It should be appreciated that the machine 90, the middleware software on the central server 120, and the communication device 200 can be programmed and operated as described above to deliver any desired message to patients 12 and/or physicians 112 using the cellular network 210 alternatively or additionally. For example, patients 12 and/or physicians 112 can similarly be informed at the end of disinfection that treatment needs to be started within a countdown time to avoid the need to re-disinfect the machine 90. It is also appreciated that updating native task monitoring features, such as the calendar application of the communication device 200, can be accomplished through an Internet connection or through the cellular network 210 illustrated in Figure 5.

[00141] Referring now to Figure 6, a system 110c of the present description is illustrated. System 110c, in the illustrated embodiment, operates with system 10 described above, including connectivity server 118, system center 120, service portal 130, enterprise resource planning system 140, network portal 150, and business intelligence portal 160, which are illustrated in Figure 6 as being part of a cloud environment, but may alternatively be located on one or more dedicated servers. Other components of system 10, not illustrated in Figure 6, may also form part of system 110a. A single medical fluid dispensing machine 90 is illustrated for ease of description, however, multiple medical fluid dispensing machines 90 may similarly be connected to system 110b. The medical fluid dispensing machine 90 may reside in the home of the patient 12 (illustrated as being outside the home) or in a clinic 126a to 126n for the clinician 112. The medical fluid dispensing machine 90 is reconnected to the connectivity server 118 over managed connection 116 and an Internet connection 52 using, for example, modem 102 in the illustrated embodiment. In Figure 6, the connectivity server 118 and the secure managed connection 116 are used for bidirectional communication.

[00142] System hub 120, in one embodiment, stores middleware software that can be accessed by mobile communication device 200 (illustrated as the single device for ease of use, but multiple devices 200 can be similarly connected to the system 110b). The mobile communication devices 200 in Figure 6 include all the structure, functionality and alternatives described for the devices 200a and 200b illustrated in Figure 4, including the Internet connection 52. In Figure 6, a mobile communication device 200 may, but need not, download a software application ("app") from the middleware software stored in the system center 120 through its internet connection 52. The app can be operated exactly as described above with respect to figure 4, including middleware software converting an encoded message from the machine 90 into an in-app presentable format. Alternatively, or additionally, middleware software stored at the center of system 120 may convert machine code 90 into a message that is hosted on the mobile communication device of the communication device's native task monitoring feature 200, such as its application. calendar, in any of the ways described in Figure 4. The calendar application may alternatively be updated over a cellular network 210 (illustrated as an alternative by the dashed front lines in Figure 6) discussed above with respect to Figure 5 .

[00143] Figure 6 illustrates that communication can be bidirectional between medical fluid dispensing machines 90 and mobile communication devices 210. Communication between mobile communication devices 210 and middleware software on server computer 120 can occur via the Internet 52 and/or cellular network 210. Communication between the middleware software on the server computer 120 may take place via the connectivity server 118 over the secure managed connection 116, as described in detail above.

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

[00145] “Determine when to disconnect connectivity agent

114 (no communication) may depend on which or how many machine states systems 110a to 110c wish to communicate to mobile communication devices 200. For example, suppose that you only wish to inform patient 12, or physician 112, two hours before treatment preparation, that patient 12, or doctor 112, needs to turn on machine 90 to start treatment preparation. Here, the connectivity agent 114 can be turned off as soon as the patient 12, or the physician 112, starts the first stage of treatment preparation, for example, by running the self-test routine.

[00146] In another example, it may be desirable for the machine 90 to run the self-test routine automatically at some predetermined time before treatment is set to begin. Machine 90 notifies patient 12 or physician 112 when it is time to start disinfection. Here, the connectivity agent 114 can be disconnected once the patient 12, or the doctor 112, starts disinfecting the machine. In a further example, it may be desirable for the machine 90 to notify the patient 12 when disinfection is complete, so that the patient begins treatment within a specified duration of time from the end of the disinfection, so that the disinfection does not need to be repeated. Here, the connectivity agent 114 can be disconnected once the patient 12, or the doctor 112, starts treatment, e.g. after the start of the setup in which the patient is yet to be connected to the treatment lines, e.g. , arterial line 14 or venous line 16.

[00147] System 110c allows patient 12, or clinician 112, to initiate any of the above actions (and others not expressly described here) remotely. Patient 12, or physician 112, can, for example, select an icon in the app displayed on mobile communication device 200 to initiate, for example, a self-test routine or a disinfection procedure. The icon selection is transmitted via the Internet 52 to the middleware software. The middleware software can then, for example, translate, for example through a lookup table, the icon selection into an action code that is sent through the connectivity server 118 and the secure managed connection 116 to the machine. 90 whose connectivity agent 114 is turned on, allowing the action code, for the selected action, to be sent to the ACPU of the machine 50, which initiates the performance of the selected action.

[00148] In an alternative embodiment, the patient 12, or the physician 112, can, for example, record a known code in a text message by selecting a particular action to be performed on the machine 90, for example, the self-test routine or a disinfection procedure. The code can be suggestive code, such as "self test" or "disinfection". The text message is sent via the cellular network 210 to the middleware software at the center of the system 120. The middleware software converts, for example, via a lookup table, the code in text form into an action code for the selected action. Or, the code recorded by patient 12, or physician 112, may be the action code, so no conversion is necessary. In either case, the action code is sent through the connectivity server 118 and the secure managed connection 116 to the machine 90 whose connectivity agent 114 is on, allowing the action code, for the selected action, to be sent to the Machine ACPU 50, which initiates the performance of the selected action.

[00149] Figure 6 illustrates the following illustrative seven-step sequence. In step 1, the medical fluid dispensing machine 90 sends a message to the middleware software application at the center of the system 120 indicating that the machine is ready for the patient 12 to start the machine's two-hour automated self-test routine

90. In step 2, the middleware software application at the center of the system 120 sends a corresponding message, e.g. translated, to the patient's mobile communication device 200 indicating that the machine 90 is ready for the patient 12 to initiate treatment. automated self-test routine.

[00150] In step 3, a custom application downloaded to the patient's mobile communication device 200 alerts the patient 12, via an audible, visual and/or tactile alert and associated message, that the machine 90 of the patient 12 is ready to the patient starts the automated self-test routine, for example, two hours. In step 4, patient 12 uses the custom application on mobile communication device 200 to confirm that machine 90 should start its automated self-test routine.

[00151] “In step 5, the patient's mobile communication device 200 sends a message to the middleware software application at the center of the system 120 confirming that it is desirable for the patient's machine 90 to start its automated self-test routine. In step 6, the middleware software application at the center of system 120 sends (e.g., converts and sends) a message to machine 90 indicating that patient 12 has confirmed that machine 90 is about to start its automated self-test routine. In step 7, the machine 90 starts and performs its automated self-test routine.

[00152] Once the self test is performed, it is contemplated for the 110c system to perform the same steps 1 through 7 discussed above, except that the action is now a disinfection procedure rather than the automated self test routine . Here, the custom application downloaded to the patient's mobile communication device 200 may display a countdown timer for patient 12, reminding the patient how long it takes for the patient to return to the machine 90 to begin treatment. It should be appreciated that different types of medical fluid dispensing machines may have one, two, three or more different actions that the patient 12, or the physician 112, can perform before treatment begins.

[00153] With reference to systems 110a to 110c, it is contemplated to program the application on the mobile communication device 200 to be configurable by the user to select what type of notification the user would like to receive on their device 200, for example through the application itself, via text message and/or via calendar notification. System hub 120 may, in one embodiment, send all types of notifications, where mobile communication device 200 ignores communication types that the user has disabled. System hub 120, in another embodiment, stores user preferences and only sends information on selected notification types. C. Physician Device/Server Modalities

[00154] Referring now to Figures 7 through 9, an embodiment of a system 110d, having a downloadable physician-based software application ("app") 230 to a physician's mobile communication device or server, doctor or nurse 200 is illustrated on screens 232 to 236. As discussed above, mobile communication device 200 can be that of a patient 12 or a doctor/nurse/doctor 112. Screens 232 to 236 of Figures 7 to 9 illustrate that application 230 can be used in a clinic or hospital 126a to 126n, where a nurse, for example, is responsible for multiple machines 90a to 90n. Machines 90a to 90n can, again, be hemodialysis machines, peritoneal dialysis machines, CRTT machines, drug and/or nutritional fluid delivery machines, and combinations thereof.

[00155] Display 232 illustrates that application 230 can monitor, and, if desired, control multiple machines 90. In the illustrated embodiment, machines 90a to 90n are each represented by a dedicated icon 190a to 190n displayed on screen 232 from the application 230. Icons 190a to 190n in the illustrated mode are ordered on screens 232 to 236 as machines 90a to 90n are ordered in clinic 126a to 126n to help guide the doctor/nurse/doctor 112.

[00156] It is contemplated that the application 230 operates with the system center 120 as discussed here, where the system center 120 is remote from the clinic or hospital 126a to 126n and is maintained, for example, by a manufacturer of one or more than 90a to 90n machines. Application 230 can, for example, be initially developed on product development 128 illustrated in Figure 1. Application 230 can then be sent from product development 128 to system center 120 via service portal 120, as illustrated in Figures 1 through 7. Any nurse, doctor, or doctor 112 authorized to download application 230 can do so from system hub 120. After that, system hub 120 maintains the middleware software to operate with application 230 in the ways described above in systems 110a to 110c.

[00157] In an alternative embodiment, clinics 126a through 126n may maintain their own local area networks, each operating with a local system center 220. Application 230 may again be developed by product development 128 (figure 1). ) and distributed through the service portal 130 to a local system center 220 of a clinic 126a to 126n operating with the system as a whole 10. Each nurse, doctor or doctor 112 authorized to download the application 230 does so from from the local system center

220. Therefore, local system hub 220 maintains middleware software to operate with application 230 in the ways described above for system hub 120 in systems 110a through 110c. In an additional alternative embodiment, the 230 application can be developed by the 126a to 126n clinic and stored in their local system center

220.

[00158] System center 120 middleware software, or local system center 220, updates the state of each machine 90a to 90n. The nurse, doctor or doctor 112 can select an icon 190a to 190n at any time to see the current status of each machine 90a to 90n, e.g. "at rest", "self test", "disinfection" or "treating the patient ", as illustrated on screen 234 of figure 8. Other status markers are contemplated and may be different for different types of machines. The nurse, physician or doctor 112 can then select any one of "at rest", "self test", "disinfection" or "treating the patient" to return to the initial icon 190a to 190n as illustrated in Figure 9.

[00159] As discussed above, it is contemplated to shut down the connectivity agent 114 of each machine 90 when the machine is running and, in particular, when a patient 12 is connected to the machine. It is also contemplated, however, to allow the connectivity agent 114 of each machine 90a to 90n of clinics 126a to 126n to remain on until the end of disinfection, so that the middleware software at the center of the system 120, or at the center of the local system 220, can receive from each machine 90a to 90n a state change to "treating the patient". Furthermore, since each machine 90a to 90n knows the duration of its scheduled treatment, the machines can also send the programmed duration to the middleware software, which then sends the duration in the form of a countdown timer along with the change of status to "treating the patient". Here, then, when the nurse, physician, or doctor 112 selects "treating the patient" in Figure 8, they can see a countdown timer showing the time remaining for treatment, as illustrated in Figure 9.

[00160] It is contemplated that for countdown timers, connectivity agent 114 allows machines 90a to 90n to send time remaining data to system center 120 so that application 230 can display actual time remaining for each machine 90 undergoing a timed process. The 230 application takes into account alarms or other delays that 90 machines may experience. During an alarm situation, the corresponding icon 190a to 190f can display a message, such as "alarm" or "safe mode". The nurse, doctor or other 112 can then select the countdown time in Figure 9 to return to the original icon 190c, 190d and 190h illustrated in Figure 7.

[00161] The nurse, doctor or doctor 112 can also send an alert on/off icon 238 to allow or prevent state changes for machines 90a to 90n to be alerted visually, audible and/or tactilely. If the alert on/off icon 238 is "on", the application 230 of the mobile communication device 200 will provide a visual, audible and/or tactile alert each time the state of the machine changes, e.g. (i) self test started, (ii) self test completed, (iii) disinfection started, (iv) disinfection completed, (v) treatment started, (vi) treatment completed. In one embodiment, codes for (i) to (v) are sent through machines 90a to 90n via secure managed connection 116, connectivity server 118, and system center 120 or local system center 220 to be translated by the middleware software and sent to application 230, which updates the appropriate icon 190. In various embodiments, "(vi) treatment completed" may be (a) sent through machines 90a to 90n with connectivity agent 114 enabled, or (b) ) inferred when the appropriate icon countdown timer 190a to 190n expires, and where connectivity agent 114 may still be powered off.

[00162] If the alert on/off icon 238 is off, for example, if the nurse, doctor or doctor 112 does not want to be interrupted at a certain time, icons 190a to 190n are still updated as described above, but audible flaps and /or tactile are not provided. The nurse, doctor or doctor 112 can still actively view the status of each machine 90a to 90n, however, by selecting the associated icon 190a to 190n.

[00163] Screens 232 to 236 illustrate action buttons 240a to 240b (referred to here collectively as action buttons 240, or generally individually as action button 240). Any number of action buttons 240 can be provided for any type of pretreatment action required for any modality, e.g. hemodialysis, peritoneal dialysis, CRRT, drug and/or nutritional fluid delivery. In the illustrated embodiment, push buttons 240a serve to initiate a self test for machines 90, while push buttons 240b serve to initiate a disinfection sequence for machines 90.

[00164] In one embodiment, when the self test button 240a is selected, any machine 90a to 90n capable, at that time, of performing a self test, will have its corresponding icon 190a to 190n highlighted. The nurse, doctor or doctor 112 selects any of the icons 190 for the machines 90 that the nurse, doctor or doctor 112 wants to perform a self test on. These selected icons 190 can then become a "confirmation" button, which the nurse, doctor, or doctor 112 must press again to make the selected machines 90 perform their self-test. Application 230 of mobile communication device 200 then sends a corresponding self-test code to middleware software at system center 120 or local system center 220 which, if necessary, converts the self-test code into a command of self-test initiation, which is sent via connectivity server 118 via secure managed connection 116 to connectivity agent 114 of selected machine 90, which transfers the command to the ACPU of machine 50, which in turn initiates the self test.

[00165] In the illustrated mode, when the disinfection button 240b is selected, any machine 90a to 90n, capable, at that moment, of performing disinfection, has its corresponding icon 190a to 190n highlighted. The nurse, doctor or doctor 112 selects any of the icons 190 for the machines 90 that the nurse, doctor or doctor 112 wants to disinfect. These selected icons 190 can again become a "confirmation" button, which the nurse, doctor or doctor 112 has to press again to make the selected machines 90 carry out their disinfection. The application 230 of the mobile communication device 200 then sends a corresponding disinfection code to the middleware software at the system center 120, or local system center 220, which, if necessary, converts the disinfection code into a control command. disinfection initiation, which is sent via connectivity server 118 via secure managed connection 116 to connectivity agent 114 of selected machine 90, which transfers the command to the ACPU of machine 50 which, in turn, initiates disinfection.

[00166] The procedure just described for action buttons 240 may also be implemented in system 110c and implemented for other machine commands, which may vary depending on the type of machine 90. It is also contemplated that a clinic 126a may decide that it is safe enough with one or more nurses, doctors or doctors 112 present at the clinic, leave the connectivity agent 114 on during treatment or a part of treatment. In such a case, the nurse, doctor or doctor 112 can control the activities being treated to the machines 90. For example, the nurse, doctor or doctor 112 can receive and respond to alarms/alerts via the app 230 on the mobile connection device 200 , starting or stopping pumps and other facets of treatment, starting or stopping disinfection, starting or stopping preparation, and the like.

[00167] Each of systems 110a to 110d operates with some form of addressing. As discussed above, connectivity server 118 is provided in an embodiment to ensure that data is distributed in the proper form to the proper machine 90, and that data from one machine 90 is delivered in its proper form to the proper destination. In one embodiment, when a machine 90 sends data to the system center 120, or to the local system center 220, for distribution to a mobile communication device 200, the data is provided with a machine identifier that identifies the machine 90. from which the data was sent. Connectivity server 118 knows each mobile communication device 200 to which particular machine data pertains and informs system center 120, or local system center 220, which communication devices 200 should receive the data. System hub 120, or local system hub 220, can then convert the data as discussed herein. When sending, for example, converted data, the system center 120, or the local system center 220, may remove the machine identifier from the data as it is no longer needed. In system 110d, however, the machine identifier may be distributed along with, for example, the converted data, so that the application 230 knows which icon 190a to 190n to populate with the new data. Here, application 230 can remove the machine identifier once it is no longer needed.

[00168] In one embodiment, when a mobile communication device 200 sends data to system center 120, or local system center 220, for distribution to a machine 90, the data is provided with a mobile communication device identifier 200 which identifies the mobile communication device 200 from which the data is sent. System hub 120, or local system hub 220, may or may not convert data from mobile communication device 200, as discussed above, but in either case, the identifier of mobile communication device 200 is maintained for the data server. connectivity 118. The connectivity server 118 knows which machine 90 is to receive, for example, the converted data for each mobile communication device 200, and sends, for example, the converted data to each associated communication device 200. The connectivity server 118 may remove the mobile communication device identifier 200 from the data once distributed to the machine 90, as it is no longer needed.

[00169] The application 230, as described above, allows the nurse, physician or doctor 112 to configure, monitor and perhaps control treatment on a medical fluid dispensing machine 90. It is contemplated to provide similar functionality through an application for patient 12 or a caregiver for patient 12 at the patient's home (dashed box in figure 1). Connectivity may be the same as illustrated in Figures 7 to 9. However, the facility is not a clinic 126a to 126n, but rather a home or other non-clinical location such as a workplace or vacation. Also, there is typically only a single machine 90, not multiple machines from 90a to 90n. It is possible, however, that a single patient 12 could be treated across multiple machines 90, which could each be supported by the application as described herein. If patient 12 is at home but away from machine 90, the application can provide valuable information, such as the length of time remaining to start or complete a start-up procedure task, a disinfection procedure, or an auto-route. test. When the patient is being treated by the machine 90, he can see the information on its user interface 122, which can be, in itself, a tablet, as illustrated in Figure 1. But there may also be a caregiver who helps the patient 12 at home during treatment, such as a spouse, friend or nurse. The caregiver benefits from the home app by receiving status updates, time remaining for start-up procedure, time remaining for disinfection, time remaining for preparation, time remaining for treatment, information regarding whether or not the patient 12 is connected to machine 90, alerts, alarms and the like. The application, in one embodiment, requires a login and password associated with the patient to be logged in before it can be downloaded to the caregiver's mobile communication device 200, so that only authorized persons can view the patient's treatment data or information. .

Ill. Patient Engagement Modalities

[00170] The illustrative medical fluid data transfer system 10, described above with respect to Figures 1 through 9, is configured to enhance patient engagement with a medical fluid delivery treatment, such as a dialysis treatment, a treatment of renal failure, and/or a peritoneal treatment. Figure 10 illustrates an illustrative medical fluid data transfer system 1000 that is similar to the medical fluid data transfer system 10 discussed with reference to Figures 1 to 9, in accordance with an illustrative embodiment of the present description. Illustrative medical fluid data transfer system 1000 (e.g., a mobile platform) is configured to enhance a patient's engagement and/or compliance with a treatment by increasing treatment transparency, providing a patient with capabilities to control and reporting treatment-related information and/or providing access to educational material and/or real-time assistance from a physician.

[00171] Illustrative medical fluid data transfer system 1000 includes, for example, a personal mobile communication device 200a that is operated by a patient. The medical fluid data transfer system 1000 also includes a pressure monitor 104, a scale 106 and a home therapy machine 90, which are similar to the respective devices discussed above with respect to Figures 1 to 9. The communication device personal mobile 200a, home therapy machine 90, blood pressure monitor 104, and scale 106 may be located, for example, at a patient's home, a self-service clinic and/or a medical clinic attended.

[00172] Home therapy machine 90 may include any type of hemodialysis machine, peritoneal dialysis machine, CRRT machine, drug and/or nutritional fluid delivery machine, and combinations thereof. Home therapy machine 90 can provide, for example, continuous cycle peritoneal dialysis ("CCPD"), automated current flow peritoneal dialysis ("APD"), and continuous flow peritoneal dialysis ("CFPD"). The home therapy machine 90 can perform the drain, supply and stay cycles automatically, typically while a patient sleeps.

[00173] The dialysis solution for peritoneal dialysis may include a solution or mixture that includes between 0.5% and 10% dextrose (or more generally glucose), preferably between 1.5% and 4.25%. The dialysis solution for peritoneal dialysis may include, for example, Dianeal&, Physioneal&, Nutrineal, and Extraneal&Oo dialysis solutions marketed by the assignee of the present disclosure. The dialysis solution may additionally or alternatively include a percentage of icodextrin.

[00174] In both hemodialysis and peritoneal dialysis, "adsorbent" technology can be used to remove uremic toxins from dialysis slurry solution, reinject therapeutic agents (such as fons and/or glucose) into the treated fluid, and reuse this fluid to continue the patient's dialysis. A commonly used adsorbent is made from zirconium phosphate, which is used to remove ammonia generated from the hydrolysis of urea. Typically, a large amount of adsorbent is required to remove the ammonia generated during dialysis treatments.

[00175] Illustrative weighing scale 106 includes any device configured to measure a mass of a patient or treatment component. For example, weighing scale 106 can measure a patient's weight before, during and/or after a renal failure therapy treatment. Additionally, or alternatively, the weighing scale 106 can measure a supply or drain bag to monitor renal failure therapy. Specifically, weighing scale 106 can be used to measure an amount of UF removed or an amount of fluid delivered to a patient. The weighing scale 106 may display a digital value indicative of the weight. Alternatively, weigh scale 106 may display a physical scale or disc that aligns with a marker to indicate a measured weight. In some embodiments, the weigh scale 106 may store the weight values before,

during and/or after treatment in separate windows, so that the patient record is necessary to view all values when medical information is recorded.

[00176] Illustrative blood pressure monitor 104 includes any device configured to measure a patient's blood pressure and/or pulse. For example, blood pressure monitor 104 can measure a patient's blood pressure before, during, and/or after a renal failure therapy treatment. Blood pressure monitor 104 may display a digital value indicative of the patient's blood pressure. Alternatively, blood pressure monitor 104 may display a physical scale with a disc that aligns with a numerical value to indicate a measured blood pressure. In some embodiments, blood pressure monitor 104 may store blood pressure values before, during, and/or after treatment in separate windows, so that the patient record is required to view all values when medical information is recorded. . Blood pressure monitor 104 may be integrated with home therapy machine 90. In another embodiment, blood pressure monitor 104 may include a wearable sensor, such as a smart watch or fitness monitoring device.

[00177] In addition to obtaining medical information (e.g., medical device data) from medical devices 90, 104, and 106, illustrative personal mobile communication device 200a may also obtain medical information from a patient consumable item and/or or therapy 1006. Figure 10 illustrates an example of a consumable item 1006, which includes, for example, a renal failure therapy medical device filter, a disposable case, a blood line set, a drug delivery, and a container (e.g., a dialysis solution concentrate container, a blood anticoagulant container, a medication container, and/or a water purification container). Consumable item 1006 may also include an adsorbent cartridge or any other supply of disposables or supplies for medical treatment. The consumable item may include an identifier 1008, which is configured to provide medical information in the form of consumption information or consumption data. For example, identifier 1008 may include information that identifies a consumable item type, a serial number, and/or consumable item properties. In some cases, consumable item 1006 may also include a label containing medical information, such as chemical composition properties. A patient or physician uses the personal mobile communication device. 200a to record images of identifier 1008, images of consumables labels 1006, and/or images of consumables 1006 themselves onto document materials used during a treatment.

[00178] Personal mobile communication device 200a may be communicatively coupled to home therapy machine 90, blood pressure monitor 104, and/or scale 106 via a wired connection (e.g., a USB connection) or a wireless connection (eg, Bluetooth'y, WiFi'v, Zigbee&, Z-WaveG6, Wireless USB, or a wireless local area network ("WLAN")). In other examples, personal mobile communication device 200a is not communicatively coupled to any of the home therapy machine 90, blood pressure monitor 104, and/or scale 106. In these other examples, a patient may manually record data displayed by home therapy machine 90, blood pressure monitor 104, and/or scale 106 on personal mobile communication device 200a. Still, or alternatively, in these other examples, a patient may record one or more images of the data displayed (or an identifier located on) by the home therapy machine 90, the blood pressure monitor 104 and/or the scale 106 using a camera 1004 of the personal mobile communication device 200a.

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

[00180] In some embodiments, the personal mobile communication device 200a is configured to record, demand and/or populate a patient's medical record with medical information or data. As described herein, medical information or data includes medical device data and patient data, which may refer to data or information created by, generated by, or otherwise related to medical devices, patients and/or consumption used by medical devices. For example, medical information includes prescription or programming information used by a medical device to deliver a treatment. Medical information also includes perceived data, such as fluid pressure, flow rate, conductivity, concentration, temperature, and patient data. As provided herein, patient data (e.g., vital sign data) includes perceived patient physiological information, such as the patient's blood pressure, weight, heart rate, etc. Medical information may also include subjective information, such as information that pertains to how a patient is feeling (eg, tired, fatigued, happy, excited, etc.). Medical information may be displayed on a medical device screen, provided by a physical disk or monitor of a medical device, or printed on an attached label or medical device. Accordingly, the medical device data, or medical information, includes a medical device configuration, a medical device readout, and/or a patient readout.

[00181] —Medical information also refers to information contained in an identifier attached to a patient or treatment consumable item. Specifically, medical information may include information carried by a patient identifier provided on a patient wristband for patient identification. Medical information also includes information regarding the consumable item, which can identify a consumable item type, a consumable item model, and/or properties of a consumable item, such as a dextrose level in a supply bag. of the renal failure therapy solution.

[00182] Treatment data or treatment information refers to data generated and/or transmitted by the home therapy machine 90 of figures 1 to 10. The treatment information may include a volume of fluid infused, an amount of ultrafiltration UF removed from a patient and/or a treatment time. Treatment information can also include alarms, alerts and/or diagnostic information generated by the home therapy machine.

90. Generally, treatment information is transmitted from a home therapy machine 90 to a physician server.

200b. In other embodiments, treatment information may be recorded on a mobile personal communication device 200a. In such embodiments, treatment information may be referred to as and/or may be included/processed as medical information.

[00183] As illustrated in Figure 10, some of all 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 designated device number, a serial number, a hardware number, a model number, and/or a device type among the respective medical devices 90, 104, and 106. For example, identifier 1012b of home therapy machine 90 may store a designated device number. Personal mobile communication device 200a reads identifier 1012b to determine, for example, a type of medical device for subsequent analysis and identification of medical information in recorded images from a machine screen 90. In some embodiments, identifier 1012 may , more generally, to indicate a model or type of a medical device. For example, identifier 1012c may indicate that device 106 is a weighing scale and/or indicate a model number of a weighing scale.

[00184] The identifier 1012 may include machine readable markings such as, for example, a barcode or a quick response ("QR") code. The identifier 1012 can also include human-readable text, such as a serial number, asset number, or hardware number. In some embodiments, identifier 1012 may be printed on an article physically attached to a housing of respective medical devices 90, 104, and 106, such as identifier 1012b illustrated for home therapy machine 90. Additionally, or alternatively, identifier 1012 may be displayed on a screen of some of all medical devices 90, 104, and 106. For example, a physician may select a control interface to cause home therapy machine 90 to display a window with identifier 1012b on a screen . In further embodiments, identifier 1012 may be included within a radio frequency ("RF") microchip, such as an RFID chip or NFC chip.

[00185] Illustrative medical devices 90, 104, and 106 may also include one or more control interfaces to provide control instructions. For example, home therapy machine 90 includes a control interface 1014. Control interfaces may include buttons, a control panel, or a touch screen. A control interface can be configured to allow a user to navigate to a particular window, or user interface, on a screen of the respective medical devices 90, 104, and 106. Control interfaces can also provide instructions for operating or controlling the devices. respective doctors 90, 104 and 106.

[00186] "As illustrated in Figure 10, the illustrative fluid data transfer system 1000 includes a network gateway 150, a system hub 120, and a physician server 200b (similar to the respective devices discussed in connection with the Figures of 1 to 9) to communicate with the mobile personal communication device 200a. Network portal 150, system hub 120, and/or physician server 200b transmit medical information from a patient's medical record (stored in a physician database 1010) to mobile personal communication device 200a. In addition, network portal 150, system hub 120, and/or physician server 200b may provide mobile personal communication device 200a with access to educational material or a real-time assistance session with a physician. Illustrative network gateway 150, system hub 120, and/or physician server 200b are also configured to allow mobile personal communication device 200a to provide medical information for completing a patient's medical record.

[00187] The illustrative fluid data transfer system 1000 of Figure 10 also includes a connectivity server 118, which is communicatively coupled to the home therapy machine 90. As discussed above with respect to Figures 1 to 9, the Connectivity server 118 provides bi-directional communication between Home Therapy Machine 90 and Physician Server 200b and/or Physician Database 1010. Home Therapy Machine 90 may connect to Connectivity Server 118 via the Internet.

[00188] In the illustrated example of Figure 10, the illustrative mobile personal 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, which, when executed by processor 1016, causes processor 1016 to provide features that enhance a patient's engagement and/or compliance with a treatment. Processor 1016 may comprise a set of digital and analog circuitry structured as a microprocessor, an application-specific integrated circuit ("ASIC"), controller, etc. Memory 1018 includes a volatile or non-volatile storage medium. In addition, memory 1018 can include any solid state or disk storage medium.

[00189] — As discussed in greater detail below, features of the 1002 application include displays of treatment progress information, control of which treatment programs are run by the home therapy machine 90, recording of medical information, display of educational material, and /or initiation of a care session with a physician. The 1002 application can be feature-rich or feature-light. A feature-rich application is configured for a smartphone and utilizes the native graphics, touch screen, and processing power of the 200a personal mobile communication device. A feature-light application is configured to operate a cell phone that has relatively less sophisticated graphics and reduced processing power. The cell phone may also not include a touch screen or instead have a touch screen with limited capacity.

[00190] In some embodiments, mobile personal communication device 200a may not include application 1022. Instead, mobile personal communication device 200a may utilize native applications or other installed applications to communicate with physician server 200b. For example, mobile personal communication device 200a may use text, SMS, or an email program to communicate with physician server 1020.

[00191] The illustrative physician server 200b includes an application 1020, such as the application 230 described with respect to Figures 1 through

9. Application 1020 is configured to communicate with mobile personal communication device 200a to provide improved patient engagement and/or compliance. In some embodiments, the illustrative application 1020 is configured to facilitate the storage of medical information (recorded by the mobile personal communication device 200a) to one or more patient records in the database 1010. The application 1020 may also include one or more interfaces or application programming interface ("API") to provide treatment progress data and/or medical information to the application 1002 for display on a display interface 1022 (e.g., a touch screen) on the mobile personal communication device 200th Application 1020 on physician server 200b may also provide educational material upon request from application 1002 and/or facilitate a communication session between mobile personal communication device 200a and a physician device 152.

[00192] In some cases, application 1002 on mobile personal communication device 200a and/or application 1020 on physician server 200b is configured to convert, or otherwise provide, medical information to physician database 1010 of others devices in the medical fluid data transfer system 1000 that conform to a Health Level 7 ("HL7") standard (eg, a medical standard). This conversion allows medical information to be stored in an HL7 format independently of a format when recorded on the personal mobile communication device 200a. Application 1002 and/or Application 1020 may operate as a network pipeline to continuously propagate relevant medical information from a medical device to a patient's medical record when gaps in network or device connectivity exist.

[00193] Figure 11 illustrates an illustrative diagram of operational modules of the application 1020 in the doctor server 200b of figure 10, according to an embodiment of the present description. Application 1020 may include a recording module 1102 configured to record a home therapy machine 90 and/or a mobile personal communication device 200a with a particular patient and/or patient medical records stored in the physician database 1010. As described in greater detail with reference to Fig. 12, registration may include determining a type of mobile personal communication device 200a for formatting subsequent communications.

[00194] Application 1020 may also include a data acquisition module 1104 configured to receive treatment and/or medical information from registered home therapy machine 90 and/or mobile personal communication device 200a. In addition, application 1020 may include a data access module 1106 to transmit, or otherwise provide, access to medical information stored in one or more patient records associated with a patient. The application 1020 may further include an education module 1108 configured to provide access to educational material, or help documentation, for a patient regarding their treatment and/or operation of the home therapy machine 90. In addition, the application 1020 may include a 1110 treatment control module that allows a patient (or physician) to change (or modify) a treatment program performed by the home therapy machine

90. Application 1020 may further include an assistance module 1112 that creates a real-time communication session between mobile personal communication device 200a and a medical device 152.

[00195] Each of the illustrative modules 1102 through 1112 is configured to enhance a patient's engagement with a medical fluid delivery treatment, thereby increasing a patient's compliance with a prescribed treatment. It should be appreciated that while modules 1102 to 1112 are illustrated, illustrative application 1020 may include fewer or more modules. For example, in some embodiments, education module 1108 and assistance module 1112 may be omitted. The sections below provide additional description regarding each of modules 1102 to 1112.

[00196] As discussed below, each of modules 1102 to 1112 is configured to communicate with mobile personal communication devices 200a and/or medical devices 152. In some embodiments, communications from mobile personal communication devices 200a may be addressed, generally, to clinician server 200b, network portal 150, connectivity server 118 and/or system hub 120. Messages may be routed internally to different modules 1102 and 1112 based on content and/or identifiers. For example, application 1002 can provide an identifier in a header to specify which of modules 1102 to 1112 should receive the message. For text-based messages, a physician server router 200b can determine a destination module 1102 to 1112 based on message content or previous messages. For example, the router may determine that a message received corresponds to a message previously transmitted by the data acquisition module.

1104. Based on this correspondence, the router sends the received message for processing through the data acquisition module

1104. A. Registration Module Type

[00197] Illustrative registration module 1102 is configured to register mobile personal communication device 200a and/or home therapy machine 90 with physician server 200b and/or with a patient's medical record stored in database 1010. Illustrative record module 1102 is configured to provide different types of records, which are used by data access module 1106 to determine how information should be displayed to a patient, based on what types of devices are registered. Furthermore, the data acquisition module 1104 determines how treatment information and/or medical information is to be acquired based on the record information.

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

[00199] In some modalities, there are different registration situations. For example, a patient may register a mobile personal communication device 200a by downloading the application 1002 while also registering a home therapy machine 90. In this situation, the registration module 1102 registers that the patient has installed the application 1002 on the mobile personal communication device. 200a and (separately or through app 1002) has registered the home therapy machine 90. Based on this registration, the data acquisition module 1104 determines that the app 1002 installed on the mobile personal communication device 200a should guide or warn otherwise way, the patient so that he/she acquires the medical information. In addition, data acquisition module 1104 determines that treatment information should be received from home therapy machine 90, rather than through mobile personal communication device 200a. Accordingly, data acquisition module 1104 may send a message to application 1002 disabling a user interface to acquire treatment information from home therapy machine 90 (but still allowing a user interface for manual switching, if one is prescribed for the patient). If a home therapy machine 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 therapy machine 90 in the application.

1002. Through registration, the data access module 1106 determines that the information is to be displayed through the application 1002 and accordingly uses APIs and/or other data reading components that are compatible or configured for the application 1002.

[00200] If a patient registers without downloading and/or installing the application 1002, the data acquisition module 1104 determines that the data acquisition should be prompted or guided. For example, data acquisition module 1104 may transmit text messages and/or emails to registered mobile personal communication device 200a advising a patient of certain medical information and/or treatment information (if a therapy machine domestic 90 has not been registered). The information in the messages specifies what data is needed from the patient. While this remote guidance can be used for the lightweight mobile personal communication devices 200a, it can also be used for smartphones where a patient does not wish to download or install the application 1002 on a feature rich device.

[00201] The data access module 1106 can also be configured to display information about a patient's medical record differently than if the application 1002 was not installed. For example, instead of sending data that connects in a feature-rich and well-defined user interface, the data access module 1106 can transform data into images that are transmitted via text to the mobile personal communication device 200a for visualization. Additionally, or alternatively, data access module 1106 may transmit medical record information stored as text to mobile personal communication device 200a. Thus, even without application 1002 installed, application 1020 on physician server 200b is configured to provide patient access to data using native applications on mobile personal communication device 200a.

[00202] - Figure 12 illustrates an illustrative diagram of communications between home therapy machine 90, mobile personal communication device 200a, and physician server 200b of Figures 10 and 11, in accordance with an illustrative embodiment of the present disclosure . Initially, the home therapy machine 90 registers with the physician server 200b through the register module 1102 of Fig. 11. Otherwise, the physician server 200b will have no information as to which patient register data from the home therapy machine. 90 must be stored. In some embodiments, home therapy machine 90 is pre-programmed with destination address information for connectivity server 118, system center 120, and/or clinician server 200b. The destination address may include an Internet Protocol ("IP") address and/or a HyperText Transfer Protocol (or Transport) ("HTTP") address.

[00203] “During setup, a patient (or clinician) registers a patient activation code ("PAC") on the home therapy machine 90. The PAC is originally generated and stored on the clinician server 200b and is provided to the patient when the patient receives the home therapy machine 90. The PAC may include a patient identifier or other code that is unique to the patient. Record module 1102 on physician server 200b stores the PAC generated for one or more patient records and/or record file associated with the patient. After registering the PAC, the home therapy machine 90 generates and transmits a 1202 message that includes the PAC. The message may also include a hardware identifier of home therapy machine 90 and/or an IP address assigned to home therapy machine 90. Home therapy machine 90 transmits message 1202 to the preprogrammed address, in which case, connectivity server 118. Illustrative connectivity server 118 relays message 1202 to system hub 120, which directs the message to physician server 200b. Registration module 1102 on physician server 200b registers home therapy machine 90 with the patient using the PAC. The record includes, for example, associating an identifier of the home therapy machine 90 with the patient's medical records of the patient. The log may also include the clinician server 200b storing the IP address of the home therapy machine 90 to allow messages to be transmitted to the home therapy machine

90. After registration, data acquisition module 1104 of physician server 200b stores treatment information received from home therapy machine 90 for one or more medical records associated with the patient.

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

[00205] In another embodiment, message 1204 may allow a patient to register two different forms depending on the capability of their personal mobile communication device 200a and/or personal preference. Message 1204 includes prompting, via text, for a patient to respond to text if he wishes to register his mobile personal communication device 200a as a low-resource device. A response to message 1204 is provided via text message 1206, which is directed to the registration module

1102. In turn, registration module 1102 registers mobile personal communication device 200a with an indication that application 1002 is not installed. In some cases, the 1204 message may also include text or a hyperlink advising the patient to select the hyperlink or otherwise obtain the 1002 application if desired. Message 1204 may also provide a warning or an option to select a device type, such as an Apple8& device or an Android& device. During the registration process, registration module 1102 registers mobile personal communication device 200a based on information provided by a patient and/or read from mobile personal communication device 200a.

[00206] Patient can register mobile personal communication device 200a after application 1002 is installed. In one embodiment, to register, the patient completes a registration form or fields provided by the 1002 application. The form, or fields, are configured to accept the patient's PAC. The form, or fields, may also include notices for a patient's name, email address, home address, phone number, etc. The information from the form or fields is sent in one or more messages 1206 to the network gateway 150, which transmits the message 1206 to the system center 120 for routing to the physician server 200b. Message 1206 may also include information about the device type of mobile personal communication device 200a (as determined by application 1002).

[00207] In some cases, application 1002 may be configured with a network gateway destination address 150, which is used to transmit messages. In other cases, messages 1206 may be provided to an API on the network portal 150 to register the application 1002 on the physician's server 200b. In other cases, application 1002 transmits message 1206 as one or more text messages or email messages to network gateway 150 (where network gateway 150 receives a phone number, |P address, email address, email, or other address). Illustrative registration module 1102 utilizes the PAC within message 1206 to register mobile personal communication device 200a with the medical records and/or registration file stored in database 1010. At this point, both home therapy machine 90 and mobile personal communication device 200a are registered to the same patient on the physician server 200b.

[00208] As mentioned above, in some embodiments, mobile personal communication device 200a may not include an application. In such embodiments, mobile personal communication device 200a may communicate with physician server 200b via text messages or via a web browser. Accordingly, record module 1102 of physician server 200b may transmit to mobile personal communication device 200a a text message with a hyperlink to a database or web page to complete a record. Alternatively, the text message may include a prompt for a patient to respond with their PAC. Providing the PAC through these enrollment processes allows enrollment module 1102 to associate mobile personal communication device 200a (e.g., a telephone number, hardware address, or IP address) with the appropriate patient medical records and/or or log file. B. Type of Data Acquisition Module

[00209] Figure 12 also illustrates data communication between home therapy machine 90, mobile personal communication device 200a, and physician server 200b. During operation, home therapy machine 90 generates treatment information and status information (eg, medical information). As discussed above with respect to Figures 1 to 8, treatment information includes a volume of fluid infused, an amount of ultrafiltration ("UF") removed from a patient, and/or a time of treatment. Status information includes alarms, alerts or diagnostics information. Before or after a treatment, home therapy machine 90 generates one or more messages 1208 with medical information, which is transmitted to connectivity server 118. In turn, connectivity server 118 directs message 1208 to the center of the system 120, which directs message 1208 to data acquisition module 1104 of physician server 200b. Upon receipt, data acquisition module 1104 stores medical information for a designated section of a patient's medical record (eg, patient's medical record 1302 of Fig. 13). Message 1208 may include an identifier or address of home therapy machine 90, which is used by data acquisition module 1104 to locate the appropriate medical record in database 1010.

[00210] Illustrative home therapy machine 90 may be configured to encode, label, or otherwise identify, using metadata or other data identification technique, the medical information being transmitted. Encoding or labeling allows data acquisition module 1104 (or interfaces on server 200b) to determine a context of medical information to write medical information into appropriate fields of a patient record. Additionally or alternatively, the coding or labeling can also be stored in the registry, which is later used for searching and displaying medical information.

[00211] - Figure 12 also illustrates that the mobile personal communication device 200a transmits the medical information or medical information to the physician server 200b. As described in greater detail below, mobile personal communication device 200a is configured to acquire medical information from medical devices, including devices 90, 104, and 106. Acquiring medical information may include receiving recorded information manually by a patient, via a wired or wireless connection and/or processing images recorded by camera 1004 of mobile personal communication device 200a. The acquired medical information is packaged into one or more messages 1210 and transmitted by the mobile personal communication device 200a to the network portal.

150. Message 1210 can be a text message, an email message, or a network-based message (for example, an HTTP message, an Extensible Markup Language ("XML") message, a payload of JavaScript Object Annotation ("JSON"), etc.). In some embodiments, mobile personal communication device 200a may form acquired medical information into one or more data fields prior to transmission. Generally, the medical information acquired on the mobile personal communication device 200a is less structured than the medical information generated by the home therapy machine 90. Accordingly, the mobile personal communication device 200a and/or the data acquisition module of the server 200b performs at least some processing of the medical information to provide a suitable context or structure for inclusion in a patient's medical record. Examples of the process carried out are described below in further detail.

[00212] Fig. 13 illustrates an illustrative patient data structure 1300 stored in the physician database 1010 of Fig. 10, in accordance with an illustrative embodiment of the present disclosure. Patient data structure 1300 includes separate patient records for different patients. In the illustrated example, data structure 1300 includes a patient medical record 1302 for a patient associated with identifier "DCM31913" and a patient medical record 1304 for a patient associated with identifier "GAM41215". Data structure 1300 may include additional patient medical records.

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

[00214] Also as illustrated in Figure 13, medical records 1302 and 1304 include fields for treatment and medical information. Data acquisition module 1104 stores treatment information for records 1302 and 1304 received from respective home therapy machines 90. In addition, data acquisition module 1104 stores medical information for records 1302 and 1304 received from the device. of respective mobile personal communication 200a. In some embodiments, data fields are further divided into individual fields for the data type. For example, records 1302 and 1304 may include treatment information fields for a volume of fluid infused, an amount of ultrafiltration ("UF") removed from a patient, and/or a time of treatment. Records 1302 and 1304 may also include data fields for alerts or alarms generated during a treatment and/or alarms or alerts determined on the physician server 200b based on the treatment information and/or medical information. Records 1302 and 1304 may further include medical information for a patient's weight and/or blood pressure recorded before, during, and/or after a treatment.

[00215] Treatment and/or medical device can be organized by treatment, generated date/time and/or received date/time. In some embodiments, medical records 1302 and 1304 may store communications from a patient. Communications may include images or videos recorded by the mobile personal communication device 200a relating to a treatment or a question about a treatment. Communications may also include text messages, emails, etc., sent from mobile personal communication device 200a in connection with treatment assistance. In addition, communications may include information related to a request to change or modify a treatment from mobile personal communication device 200a and/or physician device 152. Generally, medical records 1302 and 1304 are configured to store information for enhance a patient's engagement with a treatment in addition to documenting the results of a treatment and information related to a patient's engagement with the Physician Server 200b for treatments.

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

1. Manual Record of Medical Information in an Application Mode

[00217] In order to receive the structured information, the illustrative application 1002 of the personal mobile communication device 200a, in some embodiments, is configured to display prompts that indicate what medical information is required for a patient to complete the medical records of the patient. patient. Illustrative application 1002 may include a routine or algorithm that specifies which fields should be displayed to prompt about a patient's medical information. In some embodiments, the fields or screens on which the fields are displayed are arranged and/or ordered with respect to a medical fluid delivery treatment. The display of fields informs a patient what medical information is needed for a patient record.

[00218] Figures 14 and 15 illustrate illustrative diagrams of application user interfaces 1002 that allow a patient to record medical information for transmission to data acquisition module 1104. Specifically, user interface 1400 of Figure 14 prompts a patient about blood pressure information while user interface 1500 of Fig. 15 prompts a patient about medical fluid delivery information (e.g., treatment information). It should be appreciated that the application 1002 of the mobile personal communication device 200a may display other user interface screens that allow a patient to manually enter medical information. For example, the 1002 application can display user interface screens for a blood glucose level, patient temperature, patient weight, etc.

[00219] In some embodiments, the patient can manually record part of the medical information on the user interfaces 1400 or 1500 while obtaining other medical information wirelessly, or record part of the medical information through an image. In these settings, the 1002 application can be configured to allow a patient to select a source for recording information. A patient can manually record medical information after selecting a manual source from a menu of available data recording methods or by default.

[00220] After receiving medical information manually recorded by a patient, the illustrative application 1002 transmits the medical information to the data acquisition module 1104 for filling in a patient's medical record. Application 1002 and user interfaces 1400 and 1500 are configured so that data fields for receiving medical information align with data fields in one or more medical records. In some examples, the data fields may correspond to one or more APIs in the data acquisition module 1104 to write medical information directly into the designated data field of a patient's medical record. The application's user interfaces 1400 and 1500 accordingly advise a patient of medical information in a structured manner so that identification or formatting of medical information is not required.

[00221] In some embodiments, the 1002 application can be configured to display 1400 and 1500 user interfaces at designated times. For example, application 1002 may include a calendar that includes times/days at which a treatment is scheduled. At a specified time prior to treatment (e.g., 5 minutes, 15 minutes, 30 minutes, etc.), the illustrative application 1002 is configured to cause the mobile personal communication device 200a to display the user interface 1400, prompting an patient about blood pressure medical information. The warning informs a patient that a blood pressure measurement is required before starting treatment. The patient accordingly uses blood pressure monitor 104 to perform a blood pressure measurement. The patient then records the measurement values on the 1400 user interface before treatment is started.

[00222] In the illustrated embodiment, the user interface 1400 includes a systolic blood pressure data field 1402, a diastolic blood pressure data field 1404, and a pulse data field 1406. A patient may select the data field respective 1402, 1404, or 1406, causing the 1002 application to display a text record facility to record a value. The user interface 1400 also includes a field 1408 that allows a patient to specify whether the blood pressure measurement was performed standing or sitting. In addition, the user interface 1400 includes a data field 1410 that allows a user to specify a date/time that the blood pressure measurement was taken.

[00223] In some examples, a patient can select any of fields 1402 to 1410 to receive more information about performing the corresponding measurement. For example, a patient can select systolic blood pressure data field 1402, which causes application 1002 to display a tutorial instructing a patient how to take a blood pressure measurement and identify a systolic blood pressure measurement value. The tutorial can include text, text/images, an audio recording, an animation and/or a video. The tutorial can be stored locally as part of the application 1002 or can be stored on the clinician's server 200b for remote access or transmission.

[00224] User interface 1500 of Figure 15 is configured to be displayed by application 1002 when a patient is programmed to perform a manual exchange treatment and/or if a home therapy machine 90 is not registered with the physician server 200b . A manual exchange treatment of renal failure requires a patient to connect containers of dialysis fluid to their peritoneal cavity for a duration that allows spent dialysis fluid to drain, all without assistance from a machine. For manual treatment, a patient needs to record their manual exchange medical information to allow their records to reflect accurate treatment information.

[00225] Illustrative application 1002 may also be configured to display the user interface 1500 when a patient does not enroll on a home therapy machine 90. During enrollment, enrollment module 1102 may transmit a message to application 1002 indicating whether a home therapy machine 90 has been registered. If a home therapy machine has not been registered, application 1002 can be configured to display user interface 1500 and/or other user interfaces for acquiring treatment information, which can normally be transmitted by home therapy machine 90.

[00226] In the illustrated example, the user interface 1500 includes a progress through a treatment, including a solution phase, a drain phase, a fill phase, a UF or dwell phase, and a summary phase. Application 1002 may display a separate user interface for each phase prompting a patient to record the corresponding or requested treatment information. The illustrative user interface 1500 corresponds to a UF phase, as illustrated by a highlighted box 1502. The user interface 1500 includes a drain volume field 1504, a UF field 1506, and a supply volume field 1508. In the illustrated example , user interface 1500 prompts a patient to record a drain volume in data field 1504 during a drain phase and a fill volume in a data field 1508 during a fill phase. The 1500 user interface can calculate the UF value for the 1506 UF data field or ask the patient for a value.

[00227] Instead of displaying user interfaces 1400 and 1500 at designated times, application 1002 can cause an alarm to be displayed on mobile personal communication device 200a. The alarm may identify what medical information is required or include a link to any of the 1400 or 1500 user interfaces. The alarm may include a pop-up window displayed by the mobile personal communication device 200a. The alarm may also include an icon displayed adjacent to an icon for the application 1002 on a home screen of the mobile personal communication device 200a. In other embodiments, the 1002 application may not notify a patient of what medical information is required. Instead, the application 1002 may allow a patient to navigate to the desired user interface to record medical device data and/or treatment information.

[00228] In some embodiments, the application 1002 may identify at least some of the data fields of one or more user interfaces as required for registration, with other data fields being optional. The 1002 application can highlight or otherwise graphically indicate which data fields are needed (for example, by displaying a red box around the 1402 systolic blood pressure data field). Application 1002 may cause an alert message to be displayed by mobile personal communication device 200a if a required data field is not completed or not completed within a specified time. In some embodiments, the 1002 application may prevent a patient from navigating to another user interface until all required fields are filled in a user interface currently being viewed.

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

2. Wireless Recording of Medical Information in an Application

[00230] In some embodiments, a patient may select to record medical information wirelessly on their mobile personal communication device 200a. Medical information can be received on the mobile personal communication device 200a via, for example, a Bluetooth& connection, a Zigbee& connection, a Z-WaveG connection, a wireless USB connection, a wireless RF connection, an NFC connection, an infrared connection, or any other suitable wireless communication technology. In some cases, a patient may need to wirelessly pair mobile personal communication device 200a with the medical device, such as blood pressure monitor 104 and/or scale 106. In other embodiments, a patient activates a connection application (for example, an NFC app) that wirelessly reads medical information from a medical device.

[00231] In one example, a patient may pair their mobile personal communication device 200a with a blood pressure monitor 104. To record medical blood pressure information in the user interface 1400 of Fig. 14, the user selects, for example, the systolic blood pressure data field 1402. Selecting field 1402 causes the application 1002 to display a prompt asking the patient to select a data recording method (eg manual, wireless, photo, etc.). After selecting the wireless option, the 1002 app displays a menu of available wireless connection options and/or a list of paired Bluetooth& devices. The patient selects blood pressure monitor 104 from the list, which causes a menu to be displayed with available medical information. The patient selects the systolic blood pressure, which causes the systolic blood pressure value to be populated into the systolic blood pressure data field 1402. In some embodiments, the application 1002 is configured to read medical information from the blood pressure monitor. blood pressure 104 after the device is selected by the patient. Application 1002 can use data labels or metadata to determine which fields 1402 to 1410 are to be populated with medical information from blood pressure monitor 104.

[00232] In some embodiments, the application 1002 is configured to allow a patient to establish a permanent or semi-permanent connection with a medical device. During a setup operation, the 1002 application asks the patient to select a data field from the 1400 user interface. After the selection, the 1002 application asks the patient to select a paired wireless medical device (and/or select a data type from a medical device related menu). Selections made by the patient configure 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 1002 application is configured to access a remote, wireless medical device automatically to read certain medical information to fill in one or more data fields. For example, after a patient uses blood pressure monitor 104 to take a blood pressure measurement, monitor 104 transmits a ping or status message to application 1002 indicating that new data is available. Alternatively, application 1002 may poll or ping blood pressure monitor 104 to determine if new data is available. Application 1002 then reads the new data in one or more of data fields 1402 through 1410 to automatically populate user interface 1400. Application 1002 then sends the medical information to data acquisition module 1104 from the Physician Server 200b to automatically update the patient's medical record.

3. Medical Information Image Registration Mode in an Application

[00233] Illustrative application 1002 on mobile personal communication device 200a is configured to allow a patient to record medical information and/or treatment information by recording an image of a medical device or screen of a medical device. Mobile personal communication device 200a uses a camera 1004 to record one or more images. Application 1002 uses optical character recognition ("OCR") to extract text from the recorded image. Extracted text is populated into one or more data fields of an application user interface

1002. The use of images can reduce errors in recording patient or physician data.

[00234] In some embodiments, application 1002 uses rules or data templates to identify which text in an image may be selectable as medical information relevant to a data field. Otherwise, simply using an OCR feature makes all displayed text selectable. As such, a patient still needs to copy and paste the text from the image into a data field. By comparison, rules or data templates can group or identify text from an image as a field, which allows for easy selection by a patient or automatic selection for completion in a data field or a user interface.

[00235] Application 1002 data templates or rules are configured to organize or otherwise decipher text extracted from an image. The application 1002 determines or otherwise selects one or more of the data templates to establish a context for the medical information based on, for example, a position of the medical information within the image and/or labels/keywords included in the image. medical information. To determine a data template, the illustrative application 1002 may ask a patient to specify a type of medical device from which an image was recorded. Additionally, or alternatively, the 1002 application allows a patient to select a medical device template. In other embodiments, a patient may first record an image of an identifier 1012 (e.g., an identifier image), which is used by the application 1002 to determine a type, model, etc. of the corresponding medical device. Application 1002 then selects a data template or rule that matches the type, model, screen, etc. of the medical device.

[00236] Data templates define or specify data fields of certain medical information contained in an image. Generally, images include extracted text comprising medical information. In some cases, not all the medical information extracted is needed. Instead, only certain medical information in a recorded image is required for registration in a data field of a user interface or a patient's medical record. Relevant medical information refers to medical device data or medical information that is identified or selected to populate a data field of an application user interface 1002, or more generally, to populate a patient's medical record.

[00237] Figure 16 illustrates a schematic diagram of the mobile personal communication device 200a for recording and processing images for extracting medical information, according to an illustrative embodiment of the present description. The illustration of mobile personal communication device 200a is illustrative and some of the blocks may be combined, further divided, or removed. Furthermore, in some embodiments, the mobile personal communication device 200a may include additional blocks, such as a memory 1018 storing instructions, which when executed by a data processor 1602 (or, more generally, the processor 1016), make with the 1002 application to process the images to extract the medical information.

[00238] Illustrative data processor 1602 may be configured to manage the acquisition of medical information from one or more images. Such management includes displaying, via screen 1002, one or more camera messages that provide information asking a physician or patient (eg, an operator) to record certain images. Alternatively, data processor 1602 may initiate an image processing mode after a patient has selected to record medical information in one or more data fields of application 1002 using an image recording method. After an image recording method is selected, data processor 1602 is configured to acquire one or more images.

[00239] In some embodiments, data processor 1602 causes mobile personal communication device 200a to open a camera application to allow a patient to record one or more images. A patient can select which recorded images should be further processed or discarded. The selected images are analyzed for identification of text (such as medical information) to potentially populate the data fields of one or more of the 1002 application's user interfaces.

[00240] In other embodiments, the data processor 1602 may guide the patient through one or more image acquisition steps. Data processor 1602 may execute a workflow or routine based on which data fields have been selected by the patient. For example, data processor 1602 runs a blood pressure workflow to obtain an image from a blood pressure monitor based on a patient selecting systolic blood pressure data field 1402.

[00241] In one example, the data processor 1602 of Fig. 16 is configured to display camera messages that identify a medical device, a user interface window of a medical device, and/or an identifier on a medical device that must be recorded. Data processor 1602 may also display navigation messages that specify a medical device user interface window for imaging. Furthermore, data processor 1602 may display reminder messages if an image is not recorded within a predetermined period of time (e.g., five minutes). Messages may include text that provides instructions and/or identification of the intended target for image creation. Messages may also include instructions regarding how to navigate to a particular medical device user interface window using the medical device's control interfaces. The messages may further include graphic elements, such as an illustrative illustration of a medical device, a consumable item, identifier 1012, and/or a user interface window for which an image is to be recorded.

[00242] It should be appreciated that, in some embodiments, the data processor 1602 does not display messages. Instead, data processor 1602 is responsive to images recorded by a patient to determine relevant medical information. For example, after receiving an indication that an image has been recorded, data processor 1602 operates a workflow in which application 1002 asks a physician to identify a medical device from which the image was recorded. The notice may include a drop-down menu of available or common medical devices. In other examples, data processor 1602 automatically identifies medical information using one or more data templates or data labels to determine which extracted medical information is to be filled in or written into a data field of a user interface or medical record.

[00243] To record an image, the illustrative data processor 1602 and an image processor 1604 (more generally a processor 1016) provide operations to the application 1002 with respect to the camera 1004. A patient provides an indication through a user interface. camera user 1606 (e.g., a touch screen or button on personal mobile communication device 200a) to record an image. Patient triggers camera UI 1606 when, for example, a camera is focused on a medical device UI window or identifier

1012. Data processor 1602 receives the indication and instructs camera 1004 to record an image. The recorded image is transmitted from camera 1004 to image processor 1604. In addition, a copy of the image is displayed by data processor 1602 on display interface 1022 of mobile personal communication device 200a.

[00244] In some embodiments, data processor 1602 may cause a ghost image to appear on display interface 1002 that is illustrative of an image to be recorded. The ghost image is provided on top of a sequence of images provided by the camera 1004 in a preview mode. The purpose of the ghost image is to provide assistance to a physician or patient by confirming that the image to be recorded contains the desired medical information and is recorded at a suitable distance. For example, data processor 1602 may display a ghost image of a given identifier on a given medical device. The patient aligns the mobile personal communication device 200a such that an image sequence of the identifier 1012a is positionally aligned with the ghost image. The patient can then record the image of identifier 1012a. In some cases, the data processor 1602 uses image analysis to determine the deltas between the ghost image and the image sequence. Data processor 1602 may cause instructions to be displayed to prompt a patient to move mobile personal communication device 200a in a certain direction to reduce determined deltas. The data processor 1602 can determine when the deltas are below a threshold, indicating that the images are aligned. Once the images are substantially aligned, the data processor 1602 may provide a graphical indication on the display interface 1022 indicating that an image can be recorded or automatically cause the image to be recorded without recording a patient.

[00245] Data processor 1602 may provide a prompt asking the patient to accept the image. After receiving an indication through camera and user interface 1606 of acceptance, image processor 1604 may analyze the image to identify or otherwise extract text. In some cases, data processor 1602 may not ask a physician to accept an image. Instead, a patient can provide an indication through the 1606 camera and user interface to delete an image. Until an image is deleted, the image processor 1604 performs analysis to identify text.

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

[00247] In addition to performing OCR to identify text, the 1604 image processor can also be configured to identify patients, medical devices, and/or consumables using image analysis. For example, image processor 1604 can access a library of medical device images to identify a medical device within an image. In that example, the image processor 104 may use image matching routines to determine a match. Such a comparison may be performed in place of the medical device having an identifier 1012. The image processor 1604 may use similar routines and/or algorithms for identifying consumable items 1006.

[00248] Illustrative data processor 1602 is configured to decode identifiers 1012 to determine a medical device type of consumable item. Decoding may include correlating positions and thicknesses of lines and/or rectangles in relevant medical information. Coded lines and rectangles can correspond to a sequence of letters and/or numbers. For example, data processor 1602 may use the lines or rectangles of identifier 1012 to determine a device model number, medical device type, asset code, etc. Decoded identifiers 1012 may provide medically relevant information for filling into one or more data fields of an application user interface 1002. Additionally, or alternatively, decoded identifiers may be used by data processor 1602 to select a workflow to acquire images from a medical or consumer device and/or to determine a data template.

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

[00250] - Figure 17 illustrates a schematic diagram of a data template 1700, in accordance with an illustrative embodiment of the present disclosure. Illustrative data template 1700 is used by image processor 1604 (eg, application 1002) to identify extracted text as relevant medical information. Generally, medical device screens display medical information. Some of the information is relevant for inclusion in a data field of a 1002 application user interface. Other of the data may be less relevant or not relevant. Also, depending on a medical device model, the medical information may be in different locations or may have different labels. Data template 1700 is configured to specify the locations and names of medical information relevant to a particular home therapy machine 90.

[00251] Data template 1700 is stored in database 1608 with a plurality of other data templates for different types and/or models of medical devices and/or consumables. After receiving an identifier 1012 from a medical device (or specification of a medical device or data field by a patient), image processor 1604 selects a corresponding data template 1700. Additionally, or alternatively, image processor 1604 may use image processing to select a data template that best matches a recorded image using, for example, information labels or text position.

[00252] Illustrative data template 1700 of Figure 17 includes device data (or text) fields 1702, 1704, 1706 and 1708 that specify where medical information is located in a particular user interface window of a medical device . In some examples, the data template 1700 is graphical, so an image analysis is performed to align fields 1702 to 1708 with the extracted text in an image. In other examples, data template 1700 includes a file (or other data structure) having coordinates or positions for each of device data fields 1702 to 1708 with respect to an origin. The image processor 1604 identifies a source in an image with the extracted text and identifies the text for each of data fields 1702 through 1708 based on substantial combinations with the locations in the data template 1700. In some examples, the image processor 1604 image can scale the image to match a size or coordinate space of the 1700 data template.

[00253] — Some of the illustrated data fields 1702 to 1708 may include label text in addition to coordinates and/or locations. For example, device data field 1702 includes the label text "Ultra Filtering Window", while device data field 1704a includes the label text "UF Vol". The 1604 image processor combines label text with similar text extracted from an image. In some cases, combinations of label text are used exclusively to identify device data fields, rather than using position or image analysis.

[00254] “Combinations of label text, including label text for non-relevant device data fields, can be used to confirm that the image is from the correct window or screen of a medical device. For example, the 1604 image processor can combine the label text "Ultra Filtering Window" with the corresponding extracted text in a relatively equal location of a recorded image. The combination confirms that the image was recorded from an ultrafiltering window of a renal failure therapy medical device. However, the extracted text is not medical information relevant to a patient's medical record. If the label text does not match the extracted text, the 1604 image processor may display a message asking a patient to record an image of the Ultra Filtration Window of the renal failure therapy medical device.

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

[00256] Illustrative device data fields 1704a and 1704b of Fig. 17 are used by application 1002 to identify relevant medical information. In some cases, application 1002 may display an indicator or metadata indicating that device data fields 1704a and 1704b are relevant to a data field selected from a user interface (for example, user interface 1400 or 1500). By comparison, device data fields 1702, 1706, and 1708 may include an indicator or metadata indicating that the corresponding extracted data is not relevant. In the example illustrated in Figure 17, the image processor 1604 uses the label text from the data field 1704a to locate the corresponding extracted text in an image. Image processor 1604 then uses a positional relationship between device data fields 1704a and 1704b or text value markers to identify medical information extracted from the image that corresponds to the numerical value of the ultrafiltering volume. The image processor 1604 copies the extracted medical information related to the field 1704pb from the image to fill, for example, the systolic blood pressure data field 1402 of Fig. 14.

[00257] As discussed above with respect to Fig. 17, the data processor 1602 of Fig. 16 can use the known position relationships of text in an image and text labels to determine which of the extracted texts corresponds to the relevant medical information. In some embodiments, data processor 1602 selects a data template based on an indication of the model or type of medical device and/or consumable item. The indication may be determined from a previous image of an identifier 1012, received from a patient through the camera and user interface 1606 and/or specified through a selection of a data field from a user interface to the application 1002 in which the medical information must be filled in. In other examples, the data processor 1602 compares the data templates in the database 1608 with the image with the extracted text to find a match. In these other examples, the data processor 1602 uses the text labels and a text position between the image and the data templates to determine a match.

[00258] Illustrative data processor 1602 is configured, after identification of relevant medical information, to write,

or otherwise fill in, relevant medical information in one or more of the data fields of an application user interface

1002. In some embodiments, data processor 1602 is configured to automatically populate data fields of an application user interface 1002 using a data template. To automatically populate medical information, data processor 1602 compares the text, labels, and/or metadata associated with fields of a data template with the text, labels, metadata, and/or other data field information from one or more more of the application's user interfaces 1002. If at least some of the text, labels, and/or metadata match, the data processor 1602 identifies certain text (eg, numeric values) corresponding to the matching field of the data template. The identified text is written into the corresponding match data field of the 1002 application user interface.

[00259] In other embodiments, the data processor 1602 is configured to ask a patient to select one or more fields from a data template to populate one or more data fields from an application user interface 1002. Figure 18 illustrates an illustrative diagram of a patient filling in data fields 1402 to 1406 of user interface 1400, in accordance with an illustrative embodiment of the present disclosure. In the illustrated example, user interface 1400 is opened on personal mobile communication device 200a. To record medical information in data fields 1402 to 1406, a patient selects each of the data fields sequentially or together. For each selection, the 1002 application displays a prompt asking the patient how the data will be recorded. After a patient selects a photo recording method, application 1002 opens a camera application to allow a patient to record an image 1800 of a blood pressure monitor screen 104 using mobile personal communication device 200a. In some embodiments, the 1002 application may display text or graphics to assist the patient in image acquisition, as described above.

[00260] After the 1800 image is written, the 1002 application performs an OCR operation for text extraction. Application 1002 then determines a data template 1801 that matches the extracted text. In some embodiments, application 1002 combines text locations and/or labels with the text image and/or label locations in the data templates to find a matching data template. In other examples, the patient may specify an indication from the blood pressure monitor 104, which allows the application 1002 to locate the corresponding data template 1801. In other additional examples, the application 1002 may first ask a patient to record a image of identifier 1012a from blood pressure monitor 104. The identifier data is used by application 1002 to select the data template. Regardless of how the 1801 data template is identified, the 1002 application applies the 1801 data template to the extracted text in the 1800 image. This process includes the 1002 application identifying groups or fields of similar text. In some cases, the 1002 application may identify groups or fields of similar text based on the spacing between letters and/or words.

[00261] In the illustrated example in Figure 18, application 1002 provides fields 1802, 1804a, 1804b, 1806, 1808 and 1810 for different sets of texts. The patient selects the field from which the data is to be filled in in the selected data field of the user interface 1400. For example, to fill in the systolic blood pressure data field 1042, the patient selects the field 1804a. Patient selection causes application 1002 to copy at least part of the data from field 1804a into the data field

1402. Data field 1402 can include a rule that specifies that only a numeric integer can be accepted. Application 1002 reads the text from the selected field 1804a to numeric integers (ie "145"). Application 1002 then fills in the numeric integers identified in systolic blood pressure data field 1402. The patient can proceed to other fields 1404 to 1410 of user interface 1400 using image 1800. In each case, the patient can select between record data manually, wirelessly, or through an image. If a second image is required (eg prompted by application 1002 or determined by the patient), application 1002 allows the patient to record and view multiple images. Application 1002 applies the appropriate data template to each of the recorded images. The application 1002 accordingly allows a patient to record information on the user interface 1400 using one or more recorded images as if the patient were manually recording the values.

[00262] In some embodiments, the application 1002, and more specifically, the data processor 1602 performs a check on extracted data selected by a user to ensure that the values are within a predetermined range and/or of a specified type. The 1002 application can perform similar checks for data manually recorded by a patient or data received wirelessly from a medical device. Each data template and/or data field in a user interface can include metadata or rules for certain fields that provide limits or ranges of acceptable values. For example, the metadata or rules for a weight data field might specify that a predetermined acceptable range of values is between 20 kg and 200 kg. For values outside the predetermined range, the application 1002 may display an error on the display interface 1022 or ask a patient to record another image or rectify the value.

[00263] Figure 19 illustrates a flowchart of an illustrative procedure 1900 for recording medical information from an image using application 1002 of mobile personal communication device 200a, in accordance with an illustrative embodiment of the present disclosure. Although procedure 1900 is described with reference to the flowchart illustrated in Figure 19, it should be appreciated that many other methods of performing the steps associated with procedure 1900 may be used. For example, the order of many of the blocks can be changed, certain blocks can be combined with other blocks, and many of the blocks described can be optional. In addition, illustrative procedure 1900 may include optical blocks for prompting a patient to record an image of a screen and/or identifier 1012 of a medical device.

[00264] Illustrative procedure 1900 begins in one embodiment when application 1002 is launched on mobile personal communication device 200a and operates with processor 1016 to establish a wired and/or wireless connection with physician server 200b (block 1902) . Establishing a connection may include, for example, transmitting and/or receiving one or more 1903 messages that provide a device address, patient identifier, device identifier, network address, and/or protocol information to access and/or write in a patient's medical record. After opening application 1002, the patient navigates, or otherwise accesses, a user interface (e.g., user interfaces 1400 or 1500 of Figures 14 and 15) to record medical information (block 1904).

[00265] Prior to block 1906, a patient uses application 1002 to select a data field and select that medical information should be provided through the photographic record. At block 1906, mobile personal communication device 200a records an image 1907 of a medical device, consumer, patient, etc. The image may include an identifier and/or a display of a medical device. The mobile personal communication device 200a then determines or identifies the text within the recorded image (block 1908). For example, mobile personal communication device 200a may perform an OCR routine on the image. In cases where the image includes a barcode and/or a QR code, mobile personal communication device 200a decodes the barcode and/or QR code. Image or encoded data is converted to text characters or American Standard Code for Information Interchange ("ASCII"). In some embodiments, mobile personal communication device 200a may also determine data fields for identified text (block 1910). Data fields can be determined using, for example, a data template. As described above with respect to Figures 17 and 18, the data template may specify the locations of particular text and/or specify the particular text labels used to place the data fields operatively over the identified text within the recorded image. In some cases, data fields and/or data templates may be selected by a patient and/or determined from a medical device identifier 1012. Alternatively, instead of using templates, procedure 1900 may provide an indication that the newly recorded image has medical information relevant to extraction, selection and/or transfer.

[00266] Illustrative procedure 1900 continues in one embodiment by determining whether there are additional images to be recorded (decision block 1912). In one example, procedure 1900 can access a list of images that need to be recorded for a specified therapy or treatment. Procedure 1900, through mobile personal communication device 200a, may guide a patient through a sequence to obtain all necessary images or provide prompts to obtain images containing medical information that is determined to be needed or is missing. In other cases, the patient can determine which images are needed. If additional images need to be written, procedure 1900 returns to block

1906.

[00267] If no additional images are required, as determined in decision block 1912, a patient starts the process of filling in the relevant medical information in the data fields of a user interface. The process in the illustrated modality includes allowing the patient to select an image from the relevant medical information that is to be transferred. Image selection causes mobile personal communication device 200a to display the image on display interface 1022 (block 1914). It should be noted that the selected image includes the identified text, and, optionally, the data fields. The patient can also specify the data field (or the location in the data field) of the user interface where the data needs to be filled.

[00268] Mobile personal communication device 200a receives a selection of relevant medical information and/or data fields with relevant medical information for filling in a designated data field from an application user interface

1002. Selection may be performed by the patient by pressing the area of the touch screen 1002 of the mobile personal communication device 200a that corresponds to the medical information to be filled. The selection of relevant medical information and/or fields causes the mobile personal communication device 200a, in one embodiment, to automatically fill in at least a portion of the selected text (block 1916).

[00269] After the selected text has been filled in, the mobile personal communication device 200a determines whether additional relevant medical information is to be filled in based on a selection of additional data fields from a user interface (decision block 1918). In some examples, mobile personal communication device 200a operates a sequence or routine that provides prompts for a patient to select suitable text and/or images to fill in the data fields. If there is additional relevant medical information, as determined in decision block 1918, procedure 1900 returns to blocks 1914 and 1916, where the patient specifies the image and/or relevant medical information for filling in the data field. If there is no relevant medical information to fill in, as determined in decision block 1918, the illustrative procedure ends 1900.

4. Image/Text Attachment Application Mode

[00270] Illustrative application 1002 and physician server 200b in some embodiments are configured to allow patients to provide images or text as attachments or addenda to their medical records. In the above sections, application 1002 provides user interface data fields as prompts for desired information. However, in some cases, a patient or physician may wish to provide additional information. Additionally, or alternatively, one or more of the user interfaces of the application 1002 may include data fields for text-free entry, prompts for a patient to enter text (e.g., "how are you feeling today?"), or features that allow a photo or image to be embedded as part of the record. For example, the 1400 user interface can include a photo icon adjacent to an image request of a fluid connection to the patient's abdomen, which, when selected, opens a camera application to allow a patient to attach an image to the patient's abdomen. transmission with the medical information. Images are stored in designated fields in the patient's appropriate medical record.

[00271] Illustrative application 1002 on mobile personal communication device 200a is configured to accept images and/or text provided by a patient. In one embodiment, the 1002 application is configured to allow a patient to select between a text or photo record. If a patient selects the text record, application 1002 displays a text box. A patient records the information in the text box, which is stored by the application 1002. The application 1002 may then transmit the information in one or more messages to the physician's server 200b. Application 1020 on physician server 200b determines the patient's appropriate medical record in database 1010 and locates a "note" or free text field. The 1020 app stores the text provided by the patient in the field. In some cases, the 1020 application may also include a timestamp with the recorded text. This information provides a physician with additional information about a patient, including a feedback regarding treatment.

[00272] Figure 20 illustrates an example of a user interface 2000 that may be displayed by application 1002 on mobile personal communication device 200a that allows a patient to provide a recorded image, in accordance with an illustrative embodiment of the present disclosure. The illustrative user interface 2000 includes an image title field 2002, which can be edited by a patient. The 2000 user interface also includes one or more recorded 2004 images, or a preview of the recorded image. The 1002 application is configured to allow a patient to browse a gallery folder of recorded images to select which images to transmit. A 2006 date field and a 2008 time field provide information in the 2000 user interface indicating a date/time that the displayed image was recorded. A patient may select a "trash" button to discard the 2004 image or a "upload" button to transmit the 2004 image from application 1002 to the clinician's server 200b. The 1002 App's Illustrative Photo Capture feature allows a patient to document fluid line connectivity to the 90 Home Therapy Machine or the physiological conditions related to a treatment. Application 1020 on physician server 200b is configured to attach, or otherwise connect, received image 2004 to the patient's medical record.

5. Manual/Wireless Image Registration Mode of Medical Information via Text

[00273] In some embodiments, the mobile personal communication device 200a of Figures 10 to 12 may not be able to install or operate the application 1002, or a patient may decide not to install the application 1002. However, the medical server 200b will still register the mobile personal communication device 200a during a registration process. Instead of receiving medical information through the application 1002, the data acquisition module 1104 of the medical server 200b determines that a routine or algorithm must be executed to notify, or otherwise obtain, medical information from a patient through the medical device. mobile personal communication 200a. Illustrative data acquisition module 1104 can read a record file and/or a patient's medical record to determine that mobile personal communication device 200a is registered, but application 1002 is not yet installed.

[00274] In some embodiments, the data acquisition module 1104 is configured to obtain medical information from a patient via one or more text messages. For example, at designated times, corresponding to times of prescribed treatments, data acquisition module 1104 may transmit one or more text messages asking a patient to respond with medical information using registered mobile personal communication device 200a. In other cases, the data acquisition module 1104 is configured to respond to a text from a patient to initiate a sequence or routine for acquiring medical information. In other cases, the patient may need to send a text message with medical information and/or images to the data acquisition module without a warning message.

[00275] — The illustrative data acquisition module 1104 of Figure 11 is configured to format or otherwise structure the information received for filling in one or more data fields of a patient's medical record. Generally, medical information received from a text message is not structured. In other words, the text message does not provide a clear correlation or reference with a designated field of a patient's medical record. Instead, data acquisition module 1104 is configured to determine suitable fields for medical information received in the text message.

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

[00277] In these embodiments, the data acquisition module 1104 can be configured to send follow-up texts to a patient if the text of a received text message cannot be properly placed within a data field. For example, data acquisition module 1104 may receive a message with the text comprising "blood pressure 145". Data acquisition module 1104 determines that the message can match "systolic" or "diastolic" blood pressure data fields based on the matched text. Accordingly, the data acquisition module 1104 transmits a message to the mobile personal communication device 200a with the text asking a patient whether the value is "systolic" or "diastolic".

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

[00279] Instead of receiving the messages with text, the data acquisition module 1104 can also receive messages with a photo attachment. Similar to the process described above with respect to Figures 16 to 19, the data acquisition module 1104 is configured to process the image to extract text and identify medical device data relevant to one or more of the data fields of a medical record. . Furthermore, while the above description describes the use of text messages, the data acquisition module 1104 may additionally, or alternatively, receive medical information and/or photos via other means of communication, such as email. , instant or network-based messaging, social media posts, etc.

[00280] Figure 21 illustrates a schematic diagram of a patient medical template 2100 that can be used by the data acquisition module 1104 of the doctor server 200b to populate data fields of a patient's medical record, according to an embodiment illustrative of the present description. Template fields 2100 can match or otherwise be linked or referenced to data fields in a patient's medical record. In other embodiments, a copy of a completed 2100 template may be stored in a medical record or as a medical record itself. In some embodiments, the patient's medical template 2100 may be part of or otherwise integrated with a patient's medical record.

[00281] Illustrative template 2100 includes predefined fields 2102, 2104, 2106, 2108, 2110, 2112, 2114, 2116, 2118, and 2120 that correspond to a renal failure therapy ("RFT") treatment. Illustrative data acquisition processor 1104 may select template 2100 based on the treatment prescribed for a patient. While an RFT template 2100 is illustrated, the illustrative data acquisition module 1104 can select other templates configured specifically for pre-treatment data acquisition, post-treatment data acquisition, etc. For example, a pretreatment acquisition template might include data fields for blood pressure, pulse, and weight.

[00282] “It should be appreciated that in other embodiments, the patient medical template 2100 may include more or less fields. For example, template 2100 may additionally include data fields for pre-treatment patient weight and post-treatment patient weight, patient's glucose level, and/or patient's date of birth. In another example, the template 2100 may include fields for a fill rate, a dwell time, a fluid drain or removal rate, a blood flow rate, an effluent dose, an ultrafiltration removal rate, a dialysis solution removal rate, a total dialysis solution infused, dialysis solution flow, replacement pre-flow, replacement post-flow, patient weighing scale, back pressure, excessive patient fluid signal, filtering fraction, time remaining, dialysis solution concentration, dialysis solution name, patient identifier, room identifier, care area identifier, time stamp indicating when data was generated, an alarm condition, a alert condition, and/or an event.

[00283] In some embodiments, the data acquisition module 1104 is configured to select the template 2100 based on a prompt from a patient. For example, a patient may send to the data acquisition module 1104 a message including "manual exchange" text. In response, the data acquisition module 1104 identifies and selects the template 2100 for a manual swap. In another example, a patient may send a message to data acquisition module 1104 via mobile personal communication device 200a including "pre-treatment" or "initiate treatment" text. In response, the data acquisition module 1104 identifies and selects a template to acquire necessary medical information before a treatment is initiated.

[00284] In the illustrated example of Fig. 21, the illustrative data fields include a field 2102 for a patient name, a field 2104 for a patient identifier, a field 2106 for a patient weight, a field 2108 for a blood pressure a field 2110 for a treatment date, a field 2112 for an amount of UF removed, a field 2114 for an amount of total fluid delivered to a patient, a field 2116 for a level of dextrose, a field 2118 for a treatment prescription identifier, and a field 2120 for a disposable container identifier. In cases where the renal therapy machine 90 is registered with the physician server 200b, the data acquisition module 1104 may remove at least fields 2112 to 2120 (or select a separate template with fields 2112 to 2120 omitted) as such information is already provided by machine 90. However, fields 2112 to 2180 may be used in the template if a patient is reporting a manual exchange. In addition, the 2100 template may omit fields 2102 and 2104 based on at least some of the patient information that has already been recorded.

[00285] Illustrative data fields of patient medical template 2100 may be populated from one or more different sources of medical information including device information, patient information, and/or consumable item information. For example, patient name field 2102 and patient identifier field 2104 may be populated from images recorded by mobile personal communication device 200a of a patient identifier 1012 (or an identifier 1012 worn by the patient). Blood pressure field 2108 may be filled from an image recorded by personal mobile communication device 200a of a blood pressure monitor screen 104, while weight field 2106 may be filled from an image recorded by the device personal communication device 200a from a screen of the scale 106. The date field 2110, the removed UF field 2112, and the fluid supply field 2114 may be populated from an image recorded by the mobile personal communication device 200a of a screen (illustrating a treatment status window) of the home therapy machine 90. Similarly, the dextrose level field 2116 may be filled with an image recorded by the mobile personal communication device 200a of a screen (illustrating a window configuration) of the home therapy machine 90, while the prescription identifier field 2118 can be filled in from an image recorded by the device. one screen mobile personal communication 200a (illustrating a prescription window) of home therapy machine

90. Finally, container identifier field 2120 may be populated with an image recorded by mobile personal communication device 200a of an identifier 1008 of a disposable container consumable item 1006. As discussed above, data acquisition module 1104 may receive one or more text messages for fields 2102 to 2120 instead of receiving images containing medical information.

[00286] The patient's medical template 2100 illustrated in Figure 21 is configured to be stored in the doctor's database 1010 and accessed by the doctor's server 200b illustrated in Figures 10 and 11. After receiving a request to fill out a template for a patient, the physician server 200b is configured to create a copy or create a case of the template 2100. Medical information received from the mobile personal communication device 200a is recorded by the data acquisition module 1104 in the appropriate data fields 2102 to 2120 copy or template case 2100. Once completed, the copy or case is stored in the physician's database 1010 as a patient's medical record.

[00287] In some embodiments, data acquisition module 1104 operates a routine 2150 in conjunction with, or alternatively, to the illustrative patient's medical template 2100. In some embodiments, routine 2150 may be programmed as metadata or executable code by computer to the respective data fields 2102 to 2120. In other examples, the routine 2150 may be stored in the physician's database 1010 with respect to the patient's medical template 2100. Furthermore, in these other examples, the selection of the template 2100 causes routine 2150 to run. Illustrative routine 2150 contains routine modules 2152 to 2164 that provide associations between data fields 2102 to 2120 and corresponding medical devices, identifiers 1012, and/or consumables 1006.

[00288] —At least part of the routine modules 2152 to 2164 may be associated with, or otherwise related to, data templates (eg, data template 1700 of Figure 17). Data acquisition module 1104 is configured to access a data template for a corresponding routine module 2152 to 2164 when a patient provides an image and/or text in a message. For example, while executing blood pressure routine module 2156, data acquisition module 1104 transmits a message requesting mobile personal communication device 200a for a "systolic blood pressure measurement". A patient responds with a text message containing an image of a blood pressure monitor screen or disk 104. Data acquisition module 1104 is configured to access a data template corresponding to or referred to as routine module 1156 for measurements of blood pressure. Data acquisition module 1104 then applies the data template to extract text from the image, using the procedure described above with respect to Figures 16 to 19, to identify relevant systolic blood pressure medical information for filling in the field. blood pressure data 2108 from 2100 feedback.

[00289] —Illustrative routine 2150 may be configured to start, upon a patient's request, based on one or more messages received by the data acquisition module 1104. For example, the data acquisition module 1104 may receive a message with text including "start", "start" and/or "pretreatment". Reception of the message causes data acquisition module 1104 to determine and initiate routine 2150 to populate data fields 2102 through 2120 of template 2100. In other examples, data acquisition module 1104 transmits a first message specified by the routine 2150 for a patient at a predetermined time with respect to a treatment. Data acquisition module 1104 sequentially sends messages specified by routine 2150 after receiving response messages from personal mobile communication device 200a with appropriate medical information. In this way, the data acquisition module 1104 controls an acquisition of a patient's medical information according to a predetermined sequence. Data acquisition module 1104 may not transmit a next message in a sequence defined by routine 2150 until an appropriate response message is received (and medical information is populated in designated data field 2102 to 2120 of template 2100) from of the mobile personal communication device 200a.

[00290] In the illustrated example, the patient bracelet module 2152 may include metadata or pre-formatted messages instructing a patient to register an image of a patient's bracelet. The patient wristband module 2152 may also include character checks to ensure that the medical information received complies with the text requirements for a patient's name and/or patient identifier. For example, the patient wristband module 2152 may reject or discard medical information for a patient's name that includes numbers.

[00291] The scale module 2154 may include metadata or pre-formatted messages instructing a patient to record an image of the identifier 1012c and a screen of the scale 106 of figure 10. The scale module 2154 may also include health checks. characters to ensure that the medical information received is within an acceptable range of values and/or the correct unit type. In some cases, the weigh scale module 2154 may use medical information from identifier 1012c to confirm that the medical information on the scale screen 106 is the patient's weight medical information. In other cases, medical information from identifier 1012c is used to select a data template based on, for example, a model or type of weighing scale 106. The data template is used by data acquisition module 1104 to identify the relevant weighing scale medical information that has been extracted from the scale screen images 106.

[00292] Blood pressure module 2156 is similar to weigh scale module 2154 with respect to blood pressure monitor 104. Renal failure therapy ("RFT") modules 2158 to 2162 are used for home therapy machine 90 (or a manual switch) for each of the different windows from which medical information is needed. For example, module 2158 provides messages for acquiring images of identifier 1012 from home therapy machine 90 and a first window illustrating a treatment status window, while module 2160 provides one or more messages for acquiring an image of a treatment status window. configuration of home therapy machine 90, and module 2162 provides one or more messages for acquiring an image of a prescription window of home therapy machine 90.

[00293] Container module 2164 may include metadata or pre-formatted messages instructing a physician or patient to record an image of identifier 1008, a disposable container consumable item 1006, and/or a label on the packaging or container consumable product itself. It should be appreciated that routine 2150 may include additional modules if patient medical template 2100 includes additional data fields or fewer modules if template 2100 includes fewer fields.

[00294] “Once medical information is received using routine 2150, data acquisition module 1104 of request 1020 uses data checks to ensure that the data is within an acceptable range, correctly formatted, and/or in suitable units. In some cases, routine modules 2150 may include conversion or formatting instructions, which are used by data acquisition module 1104 to prepare medical information for inclusion in the respective field of template 2100 and/or the patient's medical record. Once the data is in the proper format and unit, the data acquisition module 1104 writes the medical information into the respective field of the template 2100 and/or the patient's medical record.

[00295] In alternative embodiments, the 2100 patient's medical template may not have an associated routine. Instead, data acquisition module 1104 of Fig. 11 is configured to read data fields 2102 to 2120 of patient's 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 mobile personal communication device 200a, advising a patient of the missing data.

[00296] To populate the data fields, the data acquisition module 1104, in some embodiments, can read a data field name 2102 to 2120 (and any corresponding metadata) to create and send a message to a patient asking for recording certain images. In one example, the weighing data field 2106 includes metadata that identifies a weighing scale as a related medical device. Data acquisition module 1104 determines that data field 2106 is not populated, reads the corresponding metadata, and constructs a message that instructs a patient of mobile personal communication device 200a to record an image of a weighing scale screen. . In the illustrated embodiments, the data acquisition module 1104 may sequentially progress through the template 2100 (or a patient's medical record) searching for unfilled data fields and accordingly request a patient's medical information via the displayed messages. by the mobile personal communication device in a predetermined order or sequence. For example, data acquisition module 1104 may first search for data fields associated with a patient bracelet, followed by data fields for a medical weighing device, data fields for the medical blood pressure device, and data fields for a renal failure therapy medical device.

[00297] Fig. 22 is a schematic diagram of the data acquisition module 1104 of the physician server 200b of Fig. 11, according to an illustrative embodiment of the present description. It should be appreciated that the illustration of data acquisition module 1104 is illustrative and that some of the blocks may be combined, further divided, or removed. Furthermore, in some embodiments, the data acquisition module 1104 may include additional blocks, such as a block for a user interface.

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

[00299] Illustrative data acquisition module 1104 includes a template processor 2204 configured to manage writing or filling in medical information from mobile personal communication device 200a to a patient's medical template 2100 or record. For example, upon request from a patient or physician, or automatically, the 2204 template processor selects a template from a patient's medical template database.

2206. The selected template (eg template 2100 of Figure 21) is used by template processor 2204 to operate a routine (eg, 2150 routine), if available or configured, to acquire medical information from the device mobile personal communication device 200a.

[00300] Illustrative template processor 2204 is configured to identify messages from modules of a routine (e.g., routine 2150) for transmission to mobile personal communication device 200a. In some cases, messages may be transmitted in a predetermined sequence to direct or guide a physician or patient through a process of completing a patient's medical template. For example, the gauge processor 2204 can read module 2156 of the routine 2150 of Fig. 21 and determine that a message should be transmitted asking a patient to record an image of the identifier 1012c of the scale 106. The gauge processor 2204 can be configured to wait until medical information related to the 1012c identifier is received (to fill in the data field

2106 of figure 21) before identifying the messages from the routine module 2156 that must be transmitted. In other cases, feedback processor 2204 selects messages for transmission based on messages received from mobile personal communication device 200a. For example, processor 2204 may receive medical information associated with identifier 1012c from weigh scale 106. In response to received medical information, template processor 2204 may determine that module 2154 corresponds to received data and accordingly selects the messages asking a patient to record an image of a weighing scale screen 104. As illustrated in Figure 22, mobile personal communication device 200a displays a text message from feedback processor 2204 instructing a patient to record an image from a screen 2220 of the scale 106.

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

[00302] In some embodiments, the template processor 2204 may receive a sequence of messages from a mobile personal communication device 200a containing substantially all of the medical information for the patient's medical template 2100 or a patient's medical record. In these embodiments, the template processor 2204 reads the labels, metadata, and/or device data field information provided with the data to determine a data field of the template 2100 where the data is to be populated or written. Template processor 2204, for example, combines the metadata or information from the modules (or data fields 2102 to 2120 themselves) with the labels, metadata, and/or device data field information provided with the medical information to determine the appropriate data field of the 2100 template.

[00303] After completing or otherwise completing a patient's medical template, the template processor 2204 of Fig. 22 is configured to store the completed template to the physician's database 1010. This may include filling in the medical record. using the 2100 template, where the fields in the template correspond to, are connected to, or reference fields in the patient's medical record. In other examples, writing to a medical record may include storing a completed template in a patient's medical record or storing the 2100 template as a medical record itself.

[00304] Figures 23 and 24 are flowcharts of illustrative procedures 2300 and 2350 for filling out the medical device template 2100 of figure 21 using recorded images (and/or text messages received from) by the mobile personal communication device 200a of figures 10 at 12 and 22, in accordance with an illustrative embodiment of the present description. Although procedures 2300 and 2350 are described with reference to the flow charts illustrated in Figures 23 and 24, it should be appreciated that many other methods of performing the steps associated with procedures 2300 and 2350 may be used. For example, in order that many of the blocks can be changed, certain blocks can be combined with other blocks, and many of the blocks described can be optional. In one embodiment, the order of blocks may be modified if a persistent connection does not exist between physician server 200b and mobile personal communication device 200a. Instead, in the embodiment, the mobile personal communication device 200a may first acquire and queue substantially all of the medical information relevant to a patient's medical template until a connection to the doctor's server 200b is available (or by designation). . The actions described in procedures 2300 and 2350 may be performed between multiple devices including, for example, mobile personal communication device 200a and physician server 200b.

[00305] Illustrative procedure 2300 begins in Fig. 23, when the physician server 200b of Figs. 10 to 12 receives a message 2301 from the mobile personal communication device 200a (block 2302). Message 2301 is indicative of a treatment to be performed on a patient or a request to start sending medical information. Doctor server 200b then determines a patient's medical template (e.g., patient's medical template 2100 of Fig. 21) based on the type of treatment specified in message 2301 or a prescribed treatment specified in the patient's medical record (block 2304). In cases where the clinician server 200b only provides completion of one type of template (for example, a template for renal failure therapy), message 2301 may indicate a request to start filling a blank template. In response to message 2301, physician server 200b creates a copy of the patient's physician template for completion.

[00306] After providing a patient's medical template for completion, the doctor server 200b determines at least one medical device from which medical information is needed (using a template-associated routine or reading the template itself) and, accordingly, transmits a first message from camera 2305 to mobile personal communication device 200a (block 2306). The first camera message 2305 includes instructions indicating that an image is to be recorded, for example, of an identifier 1012 of a medical device. Sometime later, the physician server 200b receives a message 2307 that includes medical information indicative of a type of medical device (e.g., medical information of an identifier 1012a) (block 2308). Physician server 200b then determines a device data template (e.g., device data template 1700 of Fig. 17) based on information included within message 2307 or specified in a patient's medical record (block 2310 ). For example, after determining that message 2307 identifies a blood pressure monitor 104 (type and/or model), physician server 200b determines or locates a device data template for the blood pressure monitor. Physician server 200b loads the device data template to identify relevant medical device data from an image received from a screen of blood pressure monitor 104 (block 2312).

[00307] Illustrative procedure 2300 continues in Fig. 24 where physician server 200b transmits a second camera message 2313 to mobile personal communication device 200a (block 2314). The second camera message 2312 can be determined based on a medical device type specified by the message 2307. In addition, the second camera message

2313 may include information for displaying a particular window (or relevant medical information) on a medical device for recording an image. Sometime later, the doctor server 200b receives a message 2315 that includes text from or an image of the medical device window (block 2316). The illustrative physician server 200b uses the identified data template to extract the relevant medical information from an image and determines or otherwise identifies the data fields of the patient's medical template that correspond to the relevant medical information (block 2318). If message 2315 includes text, physician server 200b determines or otherwise identifies patient medical template data fields that correspond to relevant medical information. The physician server 200b then populates the determined and/or identified data fields of the template with the relevant received medical information (block 2320).

[00308] “After filling in the relevant data fields, the illustrative physician server 200b determines whether additional relevant medical information is needed from the medical device associated with the relevant medical information received (decision block 2322). For example, the physician server 200b may determine that the current medical device may include additional operational windows or monitors from which relevant medical information is still required. If additional medical information is required, the illustrative physician server 200b returns to block 2314 and transmits a message from camera 2313 to another window from which the relevant medical information is required. However, if no additional medical information is needed for the current medical device, the physician server 200b determines whether medical information is needed from other medical devices (or consumable item 1006) (decision block 2324). If additional medical information is required, physician server 200b returns to block 2306 and transmits a message from camera 2305 identifying another medical device for imaging or from which to receive related medical information. If no additional medical information is needed to complete the patient's medical template 2100, the illustrative doctor's server 200b stores the completed patient's medical template 2100 in the doctor's database 1010 as a patient's medical record and procedure 2300 ends. .

[00309] Illustrative procedure 2350 begins in figure 3 by mobile personal communication device 200a transmitting a message 2301 that indicates a treatment to be performed on a patient or a request to start recording medical information (2352). Mobile personal communication device 200a then receives a message from camera 2305 from physician server 200b. Information from message 2305 is used by mobile personal communication device 200a to display a notice to a patient (block 2354). The notice may specify, for example, that an identifier 1012 of a medical device be imaged. Mobile personal communication device 200a then records an image of a medical device identifier 1012 (block 2356) based on the record from the patient. In some embodiments, the patient can record text by specifying a medical device type/model or select from a drop-down menu if an identifier is not available or if the patient is unwilling (or unable) to record an image.

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

[00311] Thereafter, mobile personal communication device 200a receives a message from camera 2313 from server 200b with information to display a prompt to a patient to record an image of a screen (or other specified area) of a medical device ( block 2360). The mobile personal communication device 200a accordingly displays a prompt to the patient with the information necessary to create an image of a medical device. In response to the prompt, the patient uses mobile personal communication device 200a to record an image of a screen (or other specified area) of the medical device (block 2362).

[00312] "In Figure 24, the illustrative procedure 2350 continues with the mobile personal communication device 200a creating a text message with the recorded image or the text recorded by the patient (block 2364). In some instances, the patient can modify or specify medical information. Mobile personal communication device 200a then transmits a message 2315 that includes the medical information or image thereof (block 2366).

[00313] The example mobile personal communication device 200a below determines whether additional medically relevant information is required for the medical device associated with the extracted medically relevant information (decision block 2368). The determination may include, for example, checking whether additional camera messages, referring to the current medical device, were received from the clinician's server (block 2360). If additional medical information is required, the illustrative personal mobile communication device 200a returns to block 2360 and processes a camera message 2313 to another window (or part of the medical device/consumable item) for which the relevant medical information if necessary. However, if no additional medical information is needed for the current medical device, mobile personal communication device 200a determines whether medical information is needed from other medical devices (or consumable item 1006) (decision block 2370). If additional medical information is required, mobile personal communication device 200a returns to block 2354 and processes a camera message 2305 that identifies another medical device for imaging. If no additional medical information is required to complete the patient's medical feedback, the mobile personal communication device 200a terminates the session, thus ending procedure 2350.

6. Manual/Wireless Recording of Medical Image Information via a Web Browser or File Transfer

[00314] In some embodiments, the data acquisition module 1104 of Figure 11 is configured to allow a patient to use the mobile personal communication device 200a to record medical information or provide images through a web browser or data transfer program. archive. The web browser or file transfer program allows the mobile personal communication device 200a to provide medical information and/or images without using the application 1002. In this embodiment, the doctor's server 200b hosts a web site, API(s) , and/or a file transfer site that receives an address or Uniform Resource Locator ("URL"). A web browser or file transfer program on mobile personal communication device 200a is configured to access the hosted web site, API(s), and/or file transfer site to transmit the medical information.

[00315] In some embodiments, the data acquisition module

1104 is configured to require a patient to register a username and password to access the web site or file transfer site. In other embodiments, the data acquisition module 1104 determines that the mobile personal communication device 200a is pre-registered and provides access. In other embodiments, data acquisition module 1104 provides a mailbox or other interface (e.g., an API) for receiving medical information and images without providing mobile personal communication device 200a with access to a more secure location.

[00316] Once a patient gains access via mobile personal communication device 200a, data acquisition module 1104, in some embodiments, provides a graphical user interface that prompts a patient for medical information and/or images. The user interface may be similar to the user interfaces 1400 and 1500 described with respect to Figures 14 and 15. Similar to the mobile personal communication device 200a, which contains the application 1002, the physician server 200b provides the user interfaces and data fields to receive medical information. Data acquisition module 1104 may also allow a patient to select a data recording method; such as text or an image.

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

[00318] Figure 25 illustrates a diagram of the physician server 200b hosting a web site or file transfer site to receive medical information via an image from the mobile personal communication device 200a, according to an illustrative embodiment of the present description. In the illustrated example, mobile personal communication device 200a is operating a web browser application 2500 that is directed to a web site 2502 that is hosted by physician server 200b. Website 2502 includes a graphical user interface for recording medical information. In this example, the mobile personal communication device 200a records an image 1800 of a screen of the blood pressure monitor 104 of Figure 10. The physician server 200b applies a data template 1801 to the image to extract the text sets, as illustrated in fields 1802, 1804, 1806, 1808 and 1810. The patient selects fields 1802, 1804, 1806, 1808 and 1810, in which the text must be filled in one or more data fields selected from the 2502 web site. the physician server 200b allows a patient to provide medical information through a web site, file transfer program, or API(s).

C. Data Access Module Type

[00319] Returning to Figure 11, the illustrative data access module 1106 is configured to provide patients and physicians with access to medical information stored in medical records in the physician's database 1010. As described above with respect to the data acquisition module 1010. data 1104, there are different possible configurations of mobile personal communication device 200a where 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 settings. To determine which configuration is in use by a particular patient, the illustrative data access module 1106 is configured to access a patient's medical record table or records to identify the mobile personal communication device 200a and/or where the application 1002 is installed.

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

[00321] Illustrative data access module 1106 may also determine whether medical and/or treatment information in a patient's medical record should be converted to a different format prior to transmission. For example, medical information and/or treatment information may be stored in a medical record in an HL7 format. However, this format is not conducive to text messages and/or apps. Illustrative data access module 1106 determines the capabilities of mobile personal communication device 200a to which data is to be transmitted. Data access module 1106 determines capabilities based on registration information that indicates whether application 1002 is installed and/or whether mobile personal communication device 200a is a feature-rich device. For viewing medical information in application 1002, data access module 1106 uses one or more APIs to convert medical information and/or treatment information from an HL7 format, for example, into a HyperText Markup Language format ( "HTML"), a JavaScript Object Annotation ("JSON") format, or in an XML format (for example, an application format). If the data access module 1106 determines that the application 1002 is not installed, the data access module 1106 converts the information from an HL7 format to a text message format or SMS message format through, for example, one or more APIs. Illustrative data access module 1106, accordingly, allows patient medical record information to be viewed by a patient, regardless of the capabilities of their mobile personal communication devices 200a.

1. Information Display Mode through Application

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

[00323] Figures 26 to 29 illustrate diagrams of application 1002 on mobile personal communication device 200a displaying medical information provided by access module 1006, in accordance with illustrative embodiments of the present description. The 1002 application can be configured to display different 2600, 2700, 2800 and 2900 user interfaces upon selection of a patient. In some cases, the 1002 application provides a menu or other selectable graphical resource that lists the different user interfaces available. The 1002 application can be configured to receive medical information through one or more APIs connected to the data fields of a patient's medical record. In other words, medical information from a patient record is arranged in blank templates that define a graphical user interface for displaying medical information.

[00324] — User interface 2600 of Figure 26 provides a first graph 2602 illustrating a total UF removed per day and a second graph 2604 illustrating an average UF removed by separate day/night swaps. It should be appreciated that the medical information displayed in graphics 2602 and 2604 may have originated from the home therapy machine 90 and/or one or more medical devices. The data access module 1106 of the doctor server 200b provides access to medical information from different sources as long as the information is already stored in a patient's medical record, thus providing information transparency for the patient.

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

[00326] Illustrative user interface 2700 of Figure 27 illustrates an average drain time for each UF exchange. Drain time is provided on a 2702 graph. Between the 2600 and 2700 user interfaces, a patient can calibrate how a treatment is progressing over time. Any deviations in treatment should be readily apparent and help convince the patient to adhere to the prescribed therapy.

[00327] Illustrative user interface 2800 includes a calendar that indicates the days a patient adhered to a treatment or therapy compared to the days a patient did not adhere to a therapy. A patient can select one of the days to view additional medical information. For example, the 2900 user interface illustrates treatment or medical information for April 26th. The information includes a total amount of UF removed during the day, in addition to a breakdown of the UF removed during a manual exchange compared to the UF removed through the home therapy machine 90. In the illustrated embodiment, the machine treatment information includes a program name, a prescribed therapy time, an actual therapy time, and an amount of UF removed. The data access module 1106 can determine whether a treatment has been adhered to based on the actual treatment time which must be within a prescribed treatment time limit. In some embodiments, the data access module 1106 and/or the data acquisition module 1104 may determine adherence at a time when medical or treatment information is received and set a corresponding indicator or other indication in the medical record of the patient. patient to reflect adherence or lack thereof.

[00328] In some examples, the treatment information for the manual exchange is registered by the patient through the application 1002 on the mobile personal communication device 200a, while the machine treatment information is received separately from the home therapy machine 90. In other examples, the 2900 user interface can display treatments that took place at a patient's home and treatments that took place at a clinic. The information can be sorted depending on which machine sent the information, a program name, treatment type, prescription, etc. User interface 2900 in the illustrated example accordingly provides a single display of the removed UF for different exchanges, thus providing patient information regarding the efficiency of a manual exchange compared to a machine operated exchange. Illustrative system 100 of Figure 10 allows information from both exchanges to be stored together (based on a day of treatment) for display and/or subsequent analysis.

2. Information Display Mode through Web Browser

[00329] In some embodiments, mobile personal communication device 200a may not have application 1002 installed. Instead, a patient may use a web browser application to access a web site or interface hosted by the physician's server 200b. In these embodiments, the data access module 1006 is configured to display medical information and/or treatment information on one or more web pages, similar to user interfaces 2600 to 2900 of Figures 26 to 29. In this embodiment, mobile personal communication device 200a accesses data access module 1106 via a web site. Selection of a user interface or feature through personal mobile communication device 200a causes data access module 1106 to display medical information within the web page. Data access module 1106 may be configured to format or create medical information and/or treatment information based on a type of web browser and/or operating system of mobile personal communication device 200a. In some cases, the data access module 1106 may request a patient's username and password before providing access to the web site.

3. Information Display Mode through Text

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

[00331] In one example, the data access module 1106 may receive a text message including "send 7 days UF data" text. In response, the data access module 1106 identifies a patient record that corresponds to the telephone number of the mobile personal communication device 200a to which the text message was received. The data access module 1106 can then use a lookup table or keyword search to identify fields in a patient's medical record, which includes matching the character sets or text related to the UF data (eg. example, "7 days from UF"). The data access module 1106 copies the matched text and creates a response message with a UF value for the previous seven days, which is transmitted to the mobile personal communication device 200a. Additionally, or alternatively, the data access module 1106 creates and transforms a 7-day graph, similar to the graph 2602 in Fig. 26. The data access module 1106 creates an image of the graph, which is transmitted to the communication device. mobile personnel 200a as an image in a text message. The image can be stored as a .jpeg, .gif, .png, etc. file. A patient of mobile personal communication device 200a can view the graph via the text message. Thus, the illustrative data access module 1106 is configured to provide patient access to medical and treatment information regardless of the capabilities and/or operating system of their mobile personal communication device 200a. In addition, data access module 1106 determines how data is to be transmitted based on record information provided by a patient and/or an indication of whether application 1002 is installed on the patient's mobile personal communication device 200a.

4. Alarm/Alert Modes

[00332] In addition to providing a display of medical and/or treatment information, the illustrative data access module 1106 of Fig. 11 is configured to determine and/or generate alarms and/or alerts for patients and/or physicians. Data access module 1106 may send alarms and/or alerts to a patient's personal mobile communication device 200a or physician's device 152. In some embodiments, data access module 1106 may include a table of rules. which specifies to which devices certain alarms/alerts are to be transmitted. A physician may use physician device 152 to subscribe to certain alarms/alerts and/or patients.

[00333] Data access module 1106 is configured to provide alarms/alerts based on how mobile personal communication device 200a is configured to display medical and/or treatment information. For example, if application 1002 is installed, data access module 1106 provides alarms/alerts through the appropriate user interface of the application

1002. In some cases, the 1002 application is configured to display a notification indicative of the alarm/alert. If application 1002 is not installed, data access module 1106 determines that an alarm and/or alert is to be transmitted via an SMS message or other text message to mobile personal communication device 200a.

[00334] In some embodiments, the data access module 1106 includes or has access to a data structure or list that specifies certain conditions under which an alarm or alert is to be generated. In one example, a condition may compare a single data value or trend (eg, a 30-day mobile doctor) to a range of acceptable values and/or a threshold (which may comprise hard and/or soft thresholds). In other examples, alarms or alerts can be generated based on multiple conditions based on comparing different types of information with respective thresholds. In some cases, the data access module 1106 determines the derived information calculated from the treatment and/or medical information, which is then compared to an acceptable range. The following are examples of alarms/alerts that can be transmitted by the data access module 1106 via text message and/or displayed within the 1002 application.

[00335] In one example, the data access module 1106 can generate an alarm or alert if it is detected that a patient is starting to deviate from a prescribed treatment. For example, upon detection that two days have passed since the treatment information was received, the data access module 1106 (operating according to an alert rule) transmits an alert message to the mobile personal communication device. 200th The alert message specifies, for example, that the patient must undergo treatment. The alert message can also include information (or a link to the information) that describes why the treatment is important or describes to the patient what happens to their body if a treatment is not performed in a timely manner. If the data access module 1106 detects, for example, four days without treatment information having been received, the data access module 1106 promotes alerting to alarm (operating according to an alarm rule). Data access module 1106 transmits the alarm to mobile personal communication device 200a and/or physician device 152 to provide an indication of the seriousness of non-adherence to a treatment. As mentioned above, alarms and/or alerts can be transmitted to the data access module 1106 based on whether or not 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 mobile personal communication device 200a to get the patient's attention.

[00336] In some instances, a patient is prescribed a manual exchange. Accordingly, the patient must provide treatment information indicative of the manual switch. Data acquisition module 1106 is configured to transmit an alarm or alert if manual exchange information is not received within a predetermined period of time (e.g., within 2 days of a scheduled treatment). Furthermore, if a manual exchange has not been completed properly (e.g., a short supply or a short dwell time), the data access module 1106 sends an alert and/or an alarm regarding the insufficient exchange. In order to determine an insufficient exchange, the data access module 1106 can compare the supply, dwell and/or drain times with pre-established acceptable ranges and/or limits. In some cases, the data access module 1106 may prompt the patient to perform a full swap.

[00337] In one example, an alarm and/or alert may be generated to indicate that a patient should select a different treatment program from a plurality of prescribed treatment programs or make an adjustment to a treatment program. In this example, an alarm or alert rule may specify that the data access module 1106 should compare a patient's blood pressure or weight to the respective change thresholds while calculating and comparing an accumulated fluid value to a threshold. The accumulated fluid value can be determined from the fluid supply and drain volumes, which indicates the fluid remaining in the patient's peritoneal cavity. If blood pressure or weight, and accumulated fluid values (or trends) are outside acceptable ranges, the data access module 1106 generates an alarm. The alarm may indicate that the patient has accumulated fluid and that a treatment program with a longer drain duration (or a shorter supply duration) must be selected (or a treatment program must be adjusted to provide a longer drain duration or a shorter duration of drainage). shorter supply duration). Data access module 1106 transmits the alarm for display on mobile personal communication device 200a. A patient can respond via application 1002 or a text message, causing the physician server 200b to make the appropriate change to the patient's prescription or therapy program.

[00338] In some embodiments, alarms and/or alerts may specify conditions under which additional information must be communicated to a patient. In such embodiments, data access module 1106 uses treatment information from home therapy machine 90 as a basis for determining whether a patient should provide medical information via mobile personal communication device 200a. In one example, the data acquisition module

1106 can access alarm rules and/or alerts that specify the conditions under which a warning or text message is sent to the patient's mobile personal communication device 200a requesting an additional weight or blood pressure measurement. For example, an alarm or alert might specify that a request for a new blood pressure measurement is required if a blood pressure value (or trend) exceeds a predetermined threshold. In other examples, an alarm or alert may specify that a request for a new blood pressure measurement is required if an accumulated fluid value or removed UF value (or trend) is outside an acceptable range. In response, the data access module 1106 transmits a text message or notification through the application 1002 for the patient to take and record a blood pressure measurement. In some cases, application 1002 may open a user interface (eg, user interface 3000 of Fig. 30) prompting the patient to record blood pressure information. If the additional data received from the mobile personal communication device 200a is not within an acceptable range, the data access module 1106 can provide an alert for an alarm that is transmitted to the physician device 152 and/or the personal communication device. mobile 200a. In this way, the data access module 1106 is configured to operate the rules that determine patient boundary conditions, which seek additional information from a patient before deciding whether further attention or action is needed on the part of a physician or patient.

[00339] In additional embodiments, data access module rules 1106 may instruct a patient to inspect and/or make a change to home therapy machine 90. In one example, a rule may specify that the data access module 1106 should transmit an alert to a patient if treatment information has not been received from the home therapy machine 90 within a defined period of time (eg, two days). In this situation, a patient may receive medical information indicative that a treatment has taken place, which the data access module 1106 uses to determine that an alert regarding adherence to a treatment is not required. Instead, the data access module 1106 determines that an alert must be transmitted to the patient to verify a network connection of the home therapy machine 90, so that the treatment information stored on the machine 90 can be retrieved. A patient may respond to the alert using the mobile personal communication device 200a to indicate that the connection has been verified. After the patient's response has been received, the data acquisition module 1104 can ping the home therapy machine 90 for the missing treatment information. If a connection can still be made, the data access module 1106 can send an alert to the patient, a physician and/or a network administrator with more specific instructions to activate the home therapy machine 90 and/or to overcome the network connectivity issue.

[00340] In another example, the data access module 1106 may include one or more rules that specify that an alert should be generated in response to the treatment information being out of range. For example, a large difference between the fluid supply and drain volumes could be indicative of a dialysis tubing leak or a connection to a patient. In response, the data access module 1106 transmits an alert to the patient asking the patient to check the fluid connections. A patient can provide a response indicating whether a leak has been detected. In response, the data access module

1106 determines whether the leak has been corrected in a subsequent treatment cycle (or priming sequence) or if the tubing needs to be replaced. Data access module 1106 can determine similar consumption issues for containers, cartridges, etc. based on treatment and/or medical information. For example, a low volume of UF removed may prompt the data access module 1106 to transmit an alert for a patient to check a connection of dialysis fluid and/or concentrate connected to the home therapy machine 90. D. Module Mode of Treatment Control

[00341] —“The Illustrative Treatment Control Module 1110 of Figure 11 is configured to allow a patient and/or physician to change a prescription and/or program on a Home Therapy Machine 90. To operate, Home Therapy Machine 90 receives one or more prescriptions for a patient. A prescription may specify a type of treatment (e.g. automated peritoneal dialysis treatment, manual exchange treatment, hemodialysis treatment, etc.), a period in which a patient must receive treatments, a dextrose level or other concentrated level. of treatment fluid, a daily amount of UF to be removed, and/or the number of times per day or the range of duration of each treatment. Each prescription can include one or more programs. A program may specify a duration of treatment, a total volume of fluid to be delivered to a patient, a number of supply, hold, and drain cycles that must be repeated, and/or an indication of whether the treatment comprises tidal therapy. Differences in programs within a prescription allow a patient or physician to change certain treatment parameters based on a patient's condition or activity.

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

[00343] In some embodiments, the illustrative treatment control module 1110 is configured to operate with respect to application 1002 on mobile personal communication device 200a and/or an application on physician device 152 to enable a patient and/or physician select a different prescription program and/or prescription. Figure 31 illustrates a diagram of a 3100 user interface of the 1002 application that allows a patient to select between three different programs: a Short Program, a Long Program, and a Weekend Program. A patient may select a program based on their activity and/or circumstances. In some embodiments, the application 1002 may display an alert from the data access module 1106 that provides a recommendation to change a program based on a detected fluid buildup, weight gain, or high blood pressure.

[00344] After the patient selects a different program through the 3100 user interface, the 1002 application sends a message to the 1110 treatment control module indicating the selection. In response to this, the treatment control module 1110 updates the patient's medical record to reflect the changed program,

including a time/date of change. In addition, treatment control module 1110 transmits a message to home therapy machine 90 providing an instruction to change the selected program. In some cases, the message may include treatment parameters for the newly selected program. The home therapy machine 90 accordingly performs an upcoming treatment based on the newly selected program. In some cases, the home therapy machine 90 may display a prompt for a patient to confirm the new program before operating according to the program.

[00345] In some embodiments, the treatment control module 1110 can check whether the patient is authorized to make a change to a program and/or whether the change is allowed. For example, the treatment control module 1110 receives an indication that a patient wants to change from the Short Program to the Long Program. The treatment 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, the treatment control module 1110 may not approve the change from Short to Long Program if the patient has already accumulated a relatively large volume of fluid. If a change cannot be made, the treatment control module 1110 sends a message to the mobile personal communication device 200a indicating the reason why the change cannot be made.

[00346] In one embodiment, the treatment control module 1110 may send a notification to the physician's device 152 indicating that the patient wishes to change a program. The treatment control module 1110 cannot communicate the change to the home therapy machine 90 until an acknowledgment is received from the physician device 152. In some embodiments, a physician may change a program and/or prescription through the control module. 1110 using its medical device 152. In these embodiments, the treatment control module 1110 may send a message for display in the application 1002 of the mobile personal communication device 200a indicating the program change and/or informing that a physician has made the change .

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

[00348] — Additionally, or alternatively, the treatment control module 1110 is configured to allow changes in treatment via text messages. In one example, a patient may send a message from mobile personal communication device 200a, including the text "treatment change". In response, the treatment control module 1110 is configured to send a response message with the different treatment program options and a corresponding code or designator next to each option. A patient can enter the designator or code in a response message to select a desired program. In another example, a patient can send a message with text consisting of, for example, "Long Program" to cause the treatment control module 1110 to change programs to the Long Program. E. Education Module Modality

[00349] Illustrative education module 1108 of Figure 11 is configured to provide educational material and/or encouragement to a patient via mobile personal communication device 200a. Similar to other modules 1102 to 1106 and 1110 in figure 11, the module — educational! 1108 is configured to provide content/information based on a configuration of the mobile personal communication device 200a. For example, if application 1002 is installed, education module 1108 is configured to select and deliver educational material through application 1002. If application is not installed, education module 1108 is configured to provide educational material through a website. network and/or text messages. In text message cases, the educational module 1108 can be configured to structure educational material so that it fits into a text message or provides a link to the educational material in the 1010 physician's database or hosted by a third-party server.

[00350] As described here, educational material may include text-based articles, audio, video, multimedia presentations, etc. Educational material may provide general information about a patient's condition, application information 1002, and/or information pertaining to the home therapy machine 90. Educational material may also focus on the patient's detected conditions (determined from his or her record). doctor) and/or feedback regarding the use of the 1002 application and/or the home therapy machine 90 made by the user.

[00351] — In addition, as described here, encouragement includes text, audio, video, or multimedia presentations designed to improve a patient's mood or help a patient adhere to a program. Encouragement can also include rewards or points. In some embodiments, the education module 1108 may be configured to provide encouragement based on detected conditions. In some cases, encouragement may be provided in combination with an alert generated by the data access module

1106. In an example of encouragement, a different level of status may be given to a patient based on a rate of adherence (eg, "Dialysis SuperStar" for near-perfect adherence).

[00352] Educational and/or encouragement material may be stored in the physician's database 1010. In addition, the education module 1108 may have access to third party material, such as from the National Institute of Health or the Cleveland Clinic&. The education module 1108 may include a rules data structure that specifies the conditions under which certain educational material and/or encouragement must be provided to the mobile personal communication device 200a.

[00353] In one example, the data access module 1106 determines that a patient is not adhering to a treatment. In addition to the 1106 data access module sending an alert, the 1108 education module can recommend or provide a link to a video regarding the importance of membership. Figure 32 illustrates an illustrative user interface 3200 of application 1002 that displays an adherence-related educational video provided by educational module 1108. Illustrative user interface 3200 also provides a list of recommended educational material based on detected patient conditions. For example, after detecting that the patient has high blood pressure from a medical record or medical information received, the educational module 1108 is configured to recommend educational content on how to reduce blood pressure. In addition, after detecting that a patient has not changed programs on a prescription, educational module 1108 dictates that educational content explaining program options should be recommended.

[00354] Illustrative educational module 1108 can also detect how a patient interacts with application 1002 and recommend educational content. For example, educational module 1108 receives feedback from application 1002 indicating that a patient has made multiple attempts to fill in a data field of a user interface (e.g., user interface 14 of Figure 4) using a recorded image. In response, the educational module 1108 may provide a notification via the application 1002 recommending that the patient read the tutorial regarding recording information using a recorded image.

[00355] Illustrative educational module 1108 may store in a patient's medical record an indication of any educational content or encouragement displayed by mobile personal communication device 200a. Such information can be useful for a clinician to determine how engaged a patient is with a treatment. The stored information can also provide an indication of the patient's level of knowledge of a treatment. F. Assistance Module Mode

[00356] The illustrative assistance module 1112 of figure 12 is configured to create a communication session between a patient and a physician. Specifically, assistance module 1112 is configured to create a communication session between a physician device 152 and mobile personal communication device 200a. Assistance module 1112 may utilize a capability of a mobile personal communication device 200a to detect a suitable communication session.

[00357] A communication session may include a video session, an audio call, a conference call, an SMS session, or a network messaging session. If the 1002 application is installed, the 1112 assistance module can access an option to select a video session, a conference session, or a network messaging session to connect a patient to a physician through the 1002 application. If application 1002 is not installed, assistance module 1112 may be limited to options regarding native communication capabilities of mobile personal communication device 200a, such as text messaging and audio calling.

[00358] In some embodiments, a patient may initiate a session. The 1002 application is configured to allow a patient to request to contact a physician, including specifying a preferred method of communication. Using a text feature of the 1002 application, a patient can send a text message including the text "help" to the assistance module 1112 to initiate a session. After a patient requests to start a session, the assistance module 1112 is configured to identify an available physician. In some embodiments, the assistance module 1112 may locate a record of physicians associated with the patient and send a ping/request message to their devices. A response received from one of the devices 152 provides an indication that the physician is available and willing to communicate with the patient. In some cases, the response may indicate the physician's method of communication. In response to a received message, assistance module 1112 initiates a communication session. This may include establishing a network call, messaging session, or audio call between a mobile personal communication device 200a and a clinician device 152. In some embodiments, instead of broadcasting a ping message to a group of physicians, the assistance module 1112 can sequentially send ping/request messages to physicians in a predetermined order (e.g. primary physician: first, physicians on duty in the same office: second, physicians on duty at the same office: a different office: third, etc.). Figure 33 illustrates a diagram of a user interface 3300 of application 1002 providing a video session with a physician. The video session allows a patient to raise concerns regarding their treatment. The video session also allows a clinician to view a real-time treatment situation or assist a patient in setting up a treatment.

[00359] In some embodiments, the assistance module 1112 may determine that a communication session is open or recommend opening a communication session. Assistance module 1112 may provide a recommendation in conjunction with data access module 1106 generating an alarm and/or alert. Assistance module 1112 may, after detecting the conditions of an alert and/or alarm, identify a physician device 152 that is available to participate in a session and then initiate a call to mobile personal communication device 200a to address an alert and/or alarm. In one example, the assistance module 1112 may attempt to create a communication session after detecting that a patient's blood pressure, weight, accumulated fluid, etc. is above a predetermined threshold or has changed significantly within a predetermined period of time.

[00360] Illustrative assistance module 1112 can determine a type of assistance being sought to identify the correct individual for connection. In addition to a doctor, the 1112 assistance module may be able to connect information technology specialists and home therapy machine specialists. Before starting a session, the 1002 application may ask a patient to identify a type of assistance (e.g. application help, machine help, clinical help, etc.). In other cases, the assistance module

1112 can determine an assistance type based on a context in which a request for a session was received. For example, after reviewing an educational training program on home therapy machine 90, assistance module 1112 determines that a subsequent request for assistance pertains to the operation of home therapy machine 90. In another example, while request 1002 is displaying a UF trending user interface, the assistance module 1112 determines that a subsequent request for assistance is related to a clinical matter.

[00361] Illustrative assistance module 1112 may be configured to record a file of a communication session in a patient's medical record. The assistance module 1112 can record a date/time of a communication session and an indication of how the session was initiated. The record may also include communication session participants in addition to a transcript of the communications. For text messages, this may include a copy of the messages. For audio or video, this can include a recording of the call or a transcript of the call. Ill. Conclusion

[00362] “It should be understood that various changes and modifications to the currently preferred embodiments described herein will be apparent to those skilled in the art. Such changes and modifications may be carried out without departing from the spirit and scope of the present matter and without diminishing its intended advantages. It is therefore intended that such changes and modifications will be covered by the appended claims.

Claims (21)

UT CLAIMS 1. A machine accessible device having instructions stored therein that are configured, when executed, to cause a machine to fill in patient medical records from a clinical system, characterized by: operating a camera to record images; operate a display interface; operating a connection interface configured to connect to a physician database, the physician database being configured to store the patient's medical records; and operating a processor to obtain medical information: display, through the display interface, a user interface with fields to be filled with medical information; after selecting a user interface data field, graphically provide, through a display interface, a first option to record medical information from an image, and a second option to record medical information through the record of text, if the first option is selected; receiving a recorded image from the camera, the recorded image including a medical device or a screen of a medical device; extract text from image; allow a selection, through the display interface, of at least a part of the text from the image; and writing the selected text from the image into the data field of the user interface as medical information; and if the second option is selected, allow text recording of the data field, through the display interface, as medical information; and after a send instruction is received, transmitting the medical information written in the data field to the data field as structured data in the at least one corresponding data field of a patient's medical record stored in the physician's database. 2. Machine-accessible device, according to claim 1, characterized in that it further comprises instructions stored therein that are configured, when executed, to cause the machine to operate the processor to: determine a data template for the text extracted in the image; process the extracted text using the data template to group the extracted text into fields; and allow a selection of at least one of the fields to write the selected text from the image in the data field of the user interface. 3. Machine accessible device according to claim 2, characterized in that the data template is configured to specify a context for the extracted text with respect to text positions within the image. 4. Machine-accessible device, according to claim 2, characterized in that it also comprises instructions stored therein that are configured, when executed, to cause the machine to operate the processor in order to determine the data template based on at least one of: (i) a selection, through the user interface, of a type of medical device; (ii) information digitized from an identifier located on the medical device, (iii) a label within the extracted text, or (iv) a relative placement of the extracted text. 5. Machine-accessible device according to claim 4, characterized in that the identifier located on the medical device includes at least one of a rapid response ("QR") code, a bar code, a serial number, or a hardware number located in a medical device housing or medical device display. 6. Machine accessible device according to claim 1, characterized in that the medical device includes at least one renal failure therapy machine, an infusion pump, an oxygen sensor, a respiration monitor, a glucose monitor, a blood pressure monitor, an ECG monitor, a weighing scale, and a heart rate monitor. 7. Machine accessible device according to claim 1, characterized in that the user interface data field is configured to receive at least one of blood pressure measurement data, pulse data, weighing data, of glucose, temperature data, manual exchange data for renal failure, subjective data, or consumption data for a consumable item. 8. Machine accessible device according to claim 7, characterized in that the consumable item includes at least one filter, a blood line set, a dialysis solution concentrate container, a blood anticoagulant container, a medication container, a disposable container, an adsorbent cartridge, and a water purification container. 9. Machine accessible device, according to claim 1, characterized in that the machine is a mobile personal communication device. 10. Method of filling in a patient's medical record from a clinical database using recorded images, characterized in that the method comprises: transmitting to a personal device a first message requesting a patient to use a camera of the personal device to record a first image of a medical device; receive, from the personal device, the first image; determining from the first image, through a processor, the first medical information that indicates a type or model of the medical device; determining, through the processor, a data template and a second message associated with the determined type or model of the medical device; transmit, through the processor, the second message to the personal device requesting that the patient use the camera to record a second image of a screen of the medical device; receiving, through the processor of the personal device, the second image; extract, through the processor, the text of the second image; processing, through the processor, the extracted text using the data template to group the extracted text in the fields; and writing, through the processor, at least part of the text from at least one of the fields as structured data in at least one corresponding data field of the patient's medical record. 11. Method, according to claim 10, characterized in that it further comprises: determining, through the processor, a correspondence between one of the fields and a record field in the patient's medical record; and writing, through the processor, at least part of the field text into the record field in the patient's medical record. 12. Method, according to claim 10, characterized in that it further comprises: determining, through the processor, a treatment time from the patient's medical record; and transmitting, through the processor, the first message before the treatment time. 13. Method, according to claim 10, characterized in that it further comprises: retrieving, in the processor of the personal device, a treatment message that indicates that a patient is about to start a treatment; and transmit, through the processor, the first message before the treatment begins. 14. Method according to claim 10, characterized in that the first image is received at the processor through a first Multimedia Messaging Service ("MMS") message and the second image is received at the processor through a second MMS message. 15. Method, according to claim 10, characterized in that it further comprises converting, through the processor, at least part of the text of at least one of the fields into a Health-Level 7 ("HL7") format before writing in the patient's medical record. 16. Method, according to claim 10, characterized in that it further comprises: comparing, through the processor, at least part of the text from at least one of the fields with a predetermined range; and writing, through the processor, at least part of the text of at least one of the fields if the at least part of the text of at least one of the fields is within the predetermined range. 17. Information transmission system for a patient, characterized in that the system comprises: a patient's home therapy machine, configured to transmit treatment information; a physician database configured to store the medical record and a log file that identifies the home therapy machine and a patient's personal device as registered devices and that identifies whether the personal device has installed an application to view treatment information and medical information; a physician server communicatively coupled to the physician database, home therapy machine, and personal device, the physician server being configured to: store treatment information and medical information in the medical record; receive an indication that at least part of the treatment information and medical information must be displayed on the personal device; determine from the log file whether the application is installed on the personal device; if the application is installed convert at least part of the treatment information and the medical information into an application format for display within the application; and transmit at least part of the treatment information and medical information converted to the personal device; and if the application is not installed convert at least part of the treatment information and medical information into text message or Short Message Service ("SMS") format, and transmit at least part of the treatment information and the medical information converted to the personal device via one or more of a text message or SMS message. 18. System, according to claim 17, characterized in that the application format includes at least one of the Extensible Markup Language ("XML") or HyperText Markup Language ("HTML") format. 19. System according to claim 17, characterized in that the indication that at least part of the treatment information and medical information is displayed on the personal device includes at least one of an application message or a text message/ SMS from personal device. 20. System, according to claim 17, characterized in that the record file is included in the medical record. 21. System according to claim 17, characterized in that the home therapy machine is configured to store a prescription with two programs, each of the programs providing parameters for operating the home therapy machine to perform a treatment, and in that the clinician's server is configured to: receive a program message from the personal device indicative of a switch to a second program from a first program; and transmitting a program instruction to the home therapy machine to switch to the second program from the first program. and. s LJ so o. hd SS / at. 8 S T gg S/S gg & 328 | 8% or 8? is 8/8 Dre E | ES 2 Ne $o5 DP 2 28% e $º Es o o =3B 3 TS É si | 8 71828 <a 3s - Das a 8 sos E8> a 282 CA ba ass Z . E) ss Ez == O ” 8 ua — oERÉ Ts u 15 53 22 IF o?” 383 * CA: LL i IE .* F 1s2 ' õ E o 3 “%— 1ES E 5 VeEeyU. 2 & =e SS Ss [o] 11-45 8 F EPT as !' TS T TS B 2 E E W'o 178 2 Soz 2s5 Fo o = OS SE so 1'É8 Ss 8 | SE ' 1 E jo S o =o ' | 8 o? 8 to! Ee 8 = | o " -” ' = 22 = s el 28s ES o 1 as == S Sl, 88% Fa 8 ja) ' 582 870 2 so 2 = 1 ag Sis sê “788 1 sc oo = 11 & Sm if) and Es ds ss Bl] as” oPº le o 35 5 1 qo 8 o ' > 8a 3 e 1 Z <||') 388 ss zo 1) |858 Es 1 hs o 25 o ? ' 88 2 o es 8 2 o 8 S 8 11 1a õ 158 320 Give 2? E 11288 11/88 = 6 1158s ' oe EE a E So = 1205 ' thesis 2> il o 1 2 SE So | E 23/ |3& 1 e | E 1 o 1122 s egg 3rd — 2 E 3 EE 8 1| 63 285 | 38 EgssLiso 3 88ER| [| |86S SO E 3 11) 27? a 6 & > = o 8 8 28) (| |202 o 1) 38 2 8 &s 18 es o 8 Ss E Ps SN ' Pv fe) E ' E = ” £ o ! = is E . bx 3E 8 IomenmemmrmmA—--— 8 & | 85 .º — Ss Tr 3S/* S 825 and õ & [8 =s8 and =|" $38 E” 8 Ee i AA a es FE grain E i Pg XEODA ã E 1 Í g) ) Ash : Rs É [ En q =. 8 H 1 O > ! ê ) FF / 3 ts á ' Ss Da PA 1 and P ôo Pá ! | Sl $ [Em |- Fo east so ' 1 À .. ao i i FU ha E. i | Í IN SE Web 8 4 : v o Ss VS DER | as Ss =) “ SE .. j- OS — o So o ennenacamenencencço i DD 267 a: “ad E 3 ó Dao “ j j i |es 2 : |sá u i i 2nd 1 AT 5 ” is CX ta FOZ Y FE) | FIG. 3 TO DO " " Ss Ss and 3 of Ty ds O C LL 8 s s | A | 3 $ sq E = Do = vVO 4 $E 4 FE ogsis assis "o L£ ve Ss 7 3 Ss | TOO W Ss o de ds o ds O O = is LL :; EL EC b-sg oa | It's the SN BE Es Vc and 2 E õ & | TO W F - Ss g z ã& els - wW e e o - Á SA S co) — r ds CL 8 Te Ns o . & A IS 8 and 4 AND And to (the PZ Do Tb TR AND IS EE & Sv bri Po nest bu P= oO if the E Only AND FA Tsaretcon | eoq) (=) 16 TE] 186 — 200 1 14 — mz : 232 [” The Axel Eee | from 16 n6 240 to 90h D O on Ç 114 And on/ a) off 14 238 114 116 116 1a 114 Bam | me po | (12) 16 TE] TT 6 . the 200 | 2 2 14 — 14? 234: OQ O ds from 16 16 240 to 20h QD O 7| Patient Disinfection Patient in — | 16 treatment 2 disinfection] | n6 Pasane treatment | 240D Dosing treatment Alert the connected! CO : 116 [At rest Self test 116 114 238 114 20e O ? 16 116 114 m FA Toba nat2On | 2 Ae) (12) 16 TE 7 186 — 200 114 — ma? : 236 The T O Ts read | from MS 16 THE O O 7 216 woven || 013 [K 16 Remaining | [PSinfession|| Remainder 116 14 114 144 ] 2406 O on/ O = | = EEE] |: ma 238 114 20e 7 O ? 116 116 14 114 if 8 o - Nê» & A = 9 o z 28 3s Ês 3 ae Ss & oo 2 o 8 as o = Ts 8 o so BS so ES 288 2? 8 gs É 8 Es 8 o o Ss s o e be ; 58 oO 8 Ss. AND ES 838 32 e. ns 8 o Ro Tr E : o es. ETA - sos ARA BE Po 3 eo [| 3 3 o E Z & s Ss Ss. ; s < o =8 Ss ' 2? s E , , Ú q AS (D SUS AV ass x = esS| z S) + 2sEZ| e & eai 7 — TS dâmensem 225 = Ps o q PR Ce 2 o o * 28E 8 X Eds Ss are S 88 | E EA 7 & e s Ss 7/88 => 8 à É 8 a o e o N ' po ToemImITra-—=O ese | now, ! | the | | 1 | 8th! ww, 88 i À e: ! | BE | | | two ! 2 " ' 17 8?! ' o 5 8 I va | | 9 EO a ! LL y4-- rar E = ET |3 ! 8 | SEr | | E 3 Ss | 2 Es | Q 1 8 - ' À Rr 1 7 <> 5. ;/ ! 7 Sã fa ! S e ! 8 18 ! - ! bx Ss 1 J ss o T ! 8 ã ! | o | ! 4 ! 1 OI a À 8 ! à o E) | & 8 ! i [STS ! ! x & | EH ! 8 | z ! ' ! ! 1 TD ! ! FE ! Eas| =, | 328%| S Foo - LEOEeLoeEnsE Na Eos =88 THE FE 8 s o E 58 8 33 eo >=" 3 Ss "3 s 8 Ss =? o Ss 8 = o E E - if 8? E a o o = T o ê s o S - É) É | ES Tr 2 2 T o Ea Es & 5º 33 = = õ 3: Ss rs ? ã o T Eb o SE 2 o 2 O o o a 8 o = VY . & ç : EA isa 7 7 E) C | E 8 u = 8 e s at 38 sê THE S to Ss 38 83 Es 38 z Ss = oo Ss 8 g =|= s S/S Es s/l B a /S|s=|S $/8|s £ E JEIS|E 8/8|o 8 And g8/8|/g Ss q? s an PP /-|? NaN N Ss Queues ejo el els S 2/7 el SIS s = S/E|8 s/ S/S 8 5/83 EE/S Ss e /E|o Z/S|E o SS /E/s| It = |. vv Elol/Elo = 21 o = le = e e & gs El 8 PlalE & a | o & a E lÇ|E 8|/8|5 E 8B/sS/|8|Ss F/8|E Ss C/E /e|/E aj joj/e 2 A jlaj|o E = o É o = s o — É 3 S o E o - = 2 2 D u o o x a x o E 3 x o Ns à 3 o o sã | 3 o 3 H 2 ag 2 ã ro à < IT'S It's 2 S 8 & 2 8 Ss Zz 2 o o 2 O 8 = 2 E E = = — — à I lat j : LE ; FO and =. ni IE) ss |Z Í $ Z//ê ã ni io: 3 3/8 : ê | [8] |3 3 “e & 3a al E PT RA 8 & €i Os ã se tt fsze LADA un à Ef VE L Ss H 2 ; $ à ||z Es 2 : z is) is /lé||8| [38/2 2/8) o o nos 3! |g//8/18| [28/8 El si ja |s|/|8) |: 7 is 1/2) is /ã €i bx = the u ESA io ETES— ' ! ! hey | ! So I o! sa DZ 4 ! ! PR 253 | ” Eo ! 8 ! ! ! | ! ! |! the | ! 8 | ! ' i í = 1 | i = the id 5 Fa rr Ú : 18 õE ; & : [88 v5 io ! j 288 ã SE 1 O ' 1 |8o E to L ! ; 8a [8ET |: i [eos oo : ! i | ão F" à : " à 3 io ! the | A | and the 11188 21 Ss ! qo Ss I 92707 v 1/88 ê | s ! The | ! | ! ——————— =——— 2. ê ao o o R 3 & s = = < 3E . oo = | vo sia - o Rx . u SE 53 "E e sc sê3 * u 8 | o 3 q Ss e In Ro ae E: Ss: E .— ..— .— ss 2 =") 1 filz AE |É g els 3 [23 2 * 8 8. & 3 [5 = sã 3 z 7 2 ã ai &| |ÉEIJEI/S, [83||8 |O) | 8 < 3) |z//3//9| [2218 El E) is 1/8 g 9 es moo. 2 = HEIN 3 € Fan! [oe = = 2 =| O = zú e ao q = TE Ê sas - = " 2/ 2É |s “x |: 8||8 8 FCSETSSEAIRA SO 3 Tl 2/1 = o se & 2 /SS/s | as nm aan = W Ê SÊ) = 22 Mobile Personal Communication Device 1900 — (200a) o 1902 1903 Establish a wired or wireless connection with a computer E) a 2 ; ; = 1904 Open user interface to record medical information 1907 1906 D Record an image of a medical device 1908 Determine the text in the recorded image 17 1910 FI a E A E O IE e rs tu e A e gua a e 2 | Determining Data Fields for Text | | 1912 io : Yes Additional images to be recorded? No 1914 Display a specified image with selectable text 1916 1917 Select text and fill in selected text in * a designated data field from a user interface 1918 Additional medical information to be transmitted? No FIG. 19 200 to 200 mo Image 345 | 2006 2008 ( j 11002 a 2 Home Log Data Calendar Trends Settings FIG. 20 8 to 8 Ss so N o bd o o uu z P ? x ?P x 2 Ni qe o a e qa o qa v ER xo 2 $ 3 SY 2 s 2 v 2 SZ : - 2 8 2 3 P Ss Ss & 2 E a TS 8 Ff 8 x + 2 o si oo 1 % 2 s 3 P " s & 3 1 & = Ê z "oa ã & ' t Z si o 1 ' q Tt 1 1 1 À ' 115 1 1 ' —= 23 à À 1 11 ii E sã uy À ) ! grape 1 ' e 1 v 1 1 NA) 1 í ! O v À ' 1 1a i 1 T 1 ' ' UV ' V À À ' 1) % 1 1 ! v % i 1 1 ' 1 1 ' ' N ' 1 1 í 1 ' 1 Po ' ' N 1 1 í E oq a 1 + 2 2 1 2 à à À 8 &$ e E É o eg 8 & 8 ' 2 3 1 s S é õ 8 SC o 3 E v 8 S 8 8 É So 8 É 8 e & S 38 3 2 E 8 Fi 8 s 8 ve ooo Ss à à É 3 à 58 8 8 8 É 2 e & & ô 5 gg 2 o oe õ E & 2 oo = So s 2 2 o += 8 o 8 E 3 s sl [Relation RJ ST je s € E pl Ex o z E SS R É 3 os 8 2 E o Ss 2? oo O o Tv o o o o T o o o Ss 3 833 2 Ss E 2? s NON 8 8 Ns S&S Ss Ss s and % on,T—-- SN = Tlg + | 83o y So) T 138 = q ' DE | Sesc s scene A SS í 11 | 89 I Ss 1 UV o | The ! = 1 of s | 1 ! ES 1 A 1 — so TZ 1 = so ES 8 2 ES ' 8 1 SB SÊ 32 os t S| 358 3 85 | kh ES 5 E oo ho 3 & Ss | Ss 1 ! ae the 1 | . tis i 2 tv ! | L ti RR | 1 Grandma | 1 go! a 2 tú 88 82 ! to | It's 28! Go Ss to | only ss | to SC or E | À ' o of 1 ! 1 ! | EA oa ES co o o e Ss E oa oa E. = S& 8 q: o o o ami og Christian Ss Rs R | Ss E 8 o - o o .- Ss so 8 2 T s8 Ts s2| || 28 FE 3 E oo ES DE wo E 8 & -) ES 2 v = ss 256 SE O ko) so 25 DO 25 3 EF £EE RE EE O So 3/8 Sl EE 9/ ES 58 o 8 > $ e ES TS TES = E os FE are Es 2º o Ss ZE Eo SS so = 8 E o 2 35 to Eos o 8 EN = S&S E o Po 8 x REA Ss ?oo O o.2 == us > O to E” E vo so 2 do oo 2 RE E Õõ 7 a XZ ú |! | 8 ! | 1 Rg! | sz o 8 e - tea E Es r oO In E ———., Ss QN Esso | and . E | f) ! ! | = ! ! u 8 | ! 8 and | go) | the NR ! QE qoo 28 e o = so õ > BL 2 = 8 = o õ Or == o E & E É o É 85 =D 2 Ss oo cg TO Wo EO Ss o E 22 om 9 sao aa Es ES WoE Co o 7 8 75 = o DE 82 2.2 so x so so = S BFlolál= O 35 IF ES = (o) Be ES S ES ESSE Wo = o I/O oo 2o sP 8 so” go Ss 2 E =o| | Eo Ee E8 Es ke 23 EO = O 50 = 8 2 o E to 578 se v oo - 8 o SS z X | | S 87º 8 || The| | 07 5 | E 2 8 8 Ó o õ É o o T o o o o o o TT - Ôo o o o o o o o) Ex) o ao 8 . E & E 8 8 b o o NS q Y o 2 o 2 Ss eao 2 o 8 o E = Ss E Co E 3 2 o go o os = Ss S 20 o laS|8 8 o EE Sos 85/S 8 3 EE ul 2 8 sc 2 o zo E 8 o 23 gs < = à 2 £o PES = [ms Ss E o = o DO E O 32 5th so S 8 ia Gs = 23 go) |3é LX o O so = o ê SE ) lg | [3rd o o to Ss o Ss | ! E E = o | Õ 7 mm | “Aah It's hi | ê > õ ua FE «Ss E ! E q Es | Fr o 85 8 If o 9 28 SS 3 + = E o ke) “ 35 So o EL o 8 FE Es o se TE 8 E 5 FE S& 56 COD SEO T 2 85 |o 3 2 8sES oo If / e /83 |/8 qoo Ee ses 28 |) |Es|S 872 8 38 SEE Seo E SS E 28 E 3 EE ES sss8 ES as E? mm É ES Toê ES oset| |8s 85 s 52 Es 2º oe 82 o & DO bo E O. sE o 8 >e E) | Aug ES 2 8 És = sê POA so Ss o 38 S EF 8.º 28 a 8 2 Pê 0 T3 8" SE Ss 8 s 2 vo 8 2 2 nd o [. Ss ooqx S Ss 3 Ê 3 Ss Ex Ss Ss 7 aeooo 8 <= = A Ss j— Do 7 $ | [O oh go 2 e Ss Bo 7 E 8 aa = mom mom a 2 [LILJU o Lo) oao LL o ; two? =|2 8 8 = ls 2 o & o o 2 - | to “|. = 18/ *É |; 38 3 || 818 o = S A 3 sf 8/5 o | Ss s [E 2|/s sã a [8/8 8 O o. s -- 1 Fr. o ê S : S 8 T Ex 8 No a s oO & E & Z SE EO = o â & â aj ã E â s 8 à 1) êÊ E a |> se É à E aj E Z 2 ã 2 E É 2 ei Ê o 2 3 3 rs 8 3 *): 33 e! 8 8 < E z & & ê S É——————— NM | = as E El is ; 818) £ â Dj gl2) 6 ê 314 8) à $ sÍ Fr â s & ê E Ê â Fe à 3 to 3 1] & ã ! Fr 8 8 € or on or on It's ss & z = e. s 8 fz 12, 3 = = 2 had) &l e. Ed à dl of E diidl : 3 asi: 3 «il & E & 7 iEcooos ê& OO O E E E |! be 00900, 322 COoOoo 3 E om 2000, 1 OOOPS & the u & & ÔÕ e :& ra = ei $ à: ê: 8 : EE, 2: 8. E 85 DM S;ç88sS dobsb Es ãst E EERSSS THIS ZÉS33 a! 8th Bases These gasstá| s tãSo & sss sa Ê 8 5 give É Bis E Ego Col e PE a 2 5 ci O 1 ÍOi Hello Ê & E & = i : si - ê Y à ê ) E Ê ã 3 ; i FE o ! The. oO oe o u oe oe Ss O & ss & x = aà Bj : $ |: 3 E ã a) & >= £ óõ õ " And ei is E <= E ss Ã.. . gg sS , 8 8 EM : 1 : is “It is law Ê à €! [SS] oh the u