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

Description

Engaging patients outside of a medical setting for an extended period of time is currently a virtually impossible task. As with acquiring a gym membership or purchasing a treadmill, many patients typically tend to be bullish. For example, from the outset, patients tend to readily adopt medical treatments (eg, medical fluid delivery treatments) that are self-administered in the patient's home. For treatment, patients need to connect themselves to a medical fluid delivery machine (or a container containing renal failure treatment fluid) in order to cleanse their blood from toxin build-up. Part of the treatment may include tasks that the patient needs to perform, such as weighing themselves, taking their blood, and/or recording information related to their treatment. Information recorded by patients is often reviewed by clinicians to ensure that treatment is progressing as prescribed. The clinician also reviews the recorded data to determine if adjustments to treatment are needed.

Over time, many patients become disengaged from treatment as it loses its novelty and becomes a routine obligation. As one can imagine, patients would rather engage in activities that are more exciting, relaxing, or stimulating compared to self-administered medical treatments. As patients continue with treatment, they sometimes begin to skip performing additional tasks associated with treatment. Skipping additional tasks and reducing motivation for treatment has the potential to create gaps in clinical supervision of ongoing treatment. As patients become more disengaged from their treatments, they may begin to skip treatments or do without them altogether, risking their health in the process.

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

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

In addition, the exemplary medical fluid data transfer system provides a gateway for the clinician to allow the patient to communicate with the clinician in real time regarding any concerns or questions about the medical fluid delivery treatment. In some embodiments, the medical fluid data transfer system also provides patient access to educational or training materials. Accordingly, the exemplary medical fluid data transfer system is configured to connect a patient to assistance needed or required to remain engaged and/or compliant with treatment.

The medical fluid data transfer systems and methodologies of the present disclosure are useful for, for example, plasmapheresis, hemodialysis ("HD"), hemofiltration ("HF"), hemodiafiltration ("HDF"), and continuous renal replacement therapy ("HD"). CRRT") is applicable to fluid delivery for treatment. 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.

The above modalities include one or more pumps, valves, heaters, if required, direct medical fluid generation equipment, pressure sensors, conductivity sensors, temperature sensors, air detectors, blood leak detection. a control unit, etc., which may employ sensors, user interfaces, and one or more processors and memory for controlling any one, more, or all of the devices, etc., and the devices described above; It may be provided by a medical fluid delivery machine that houses the components needed to deliver medical fluids. The medical fluid delivery machine also includes one or more filters, such as a dialyzer or hemofilter to clean blood and/or an ultrafilter to purify water, dialysis fluid, or other fluids. obtain.

The medical fluid delivery machines and medical fluid data transfer systems and methodologies described herein can be used with home-based machines. For example, the system may be used with home HD, HF, or HDF machines that are operated at the patient's convenience. One such home system is published on October 4, 2011, entitled "High Convection Home Hemodialysis/Hemofiltration And Sorbent System," filed on November 4, 2004, and assigned to the assignee of the present application. No. 8,029,454 ("the '454 patent"). Another such home-based system is U.S. Pat. (the '690 Patent). The entire contents of each of the above references are incorporated herein by reference and relied upon.

As described in detail below, the medical fluid data transfer systems and methodologies of the present disclosure can be applied to many machines, patients, clinicians, physicians, maintenance personnel, electronic medical records, comprising many different types of devices. (“EMR”) databases, websites, resource planning systems that handle data generated via patient and clinician communications, and business intelligence. The medical fluid data transfer system and methodology of the present disclosure operates seamlessly within the overall system without violating its rules and protocols.

In light of the disclosure herein, and without limiting the disclosure in any way, the first aspect of the disclosure may be combined with any other aspect listed herein, unless otherwise specified. In this aspect, the machine-accessible device, when executed, causes the machine to operate a camera, record an image, operate a display interface, and connect to a clinician database. operating the interface, the clinician database configured to store patient medical records; and operating the processor to retrieve the medical information, the clinician database configured to store patient medical records of the clinical system. has instructions stored thereon configured to cause the data to be populated. The processor displays, via the display interface, a user interface with fields to be populated with medical information, and after selecting the data fields of the user interface, enters the medical information from the image via the display interface. and graphically providing a first option for inputting the medical information via text input. If the first option is selected, the processor is configured to receive a recorded image from a camera, the recorded image comprising a medical device or a screen of a medical device, and to extract text from the image. extracting and enabling selection of at least a portion of the text from the image via the display interface and writing the selected text from the image as medical information to a data field of the user interface. If the second option is selected, the processor enables text entry of data fields as medical information via the display interface. The processor is also operated to obtain medical information by transmitting the medical information written in the data field to a patient medical record stored in the clinician database after the transmit command is received.

According to a second aspect of the disclosure, which may be used in combination with any other aspect recited herein, unless otherwise stated, the machine-accessible device, when executed, causes the machine to display an image. determining a data template for the extracted text above, using the data template to process the extracted text, classifying the extracted text into fields, and enabling selection of at least one of the fields; and instructions stored thereon configured to operate the processor to write selected text from the image to a data field of the user interface.

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

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

According to a fifth aspect of the present disclosure, which may be used in combination with any other aspect recited herein, unless stated otherwise, the identifier located on the medical device is located on the casing of the medical device. at least one of a quick response (“QR”) code, a bar code, a serial number, or a hardware number located on the body or screen of the medical device.

According to a sixth aspect of the disclosure, which may be used in combination with any other aspect listed herein, unless otherwise stated, the medical device comprises at least a renal failure therapy machine, an infusion pump, an oxygen sensor , respiration monitors, glucose meters, blood pressure monitors, ECG monitors, weight scales, and heart rate monitors.

According to a seventh aspect of the present disclosure, which may be used in combination with any other aspect recited herein, unless stated otherwise, the data fields of the user interface include blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual replacement data, subjective data, or consumable data regarding a consumable item.

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

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

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

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

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

According to a thirteenth aspect of the disclosure, which may be used in combination with any other aspect recited herein, unless otherwise stated, the method comprises: in a processor, from a personal device, a patient initiates treatment; and transmitting, via the processor, a first message before the therapy is initiated.

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

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

According to a seventeenth aspect of the present disclosure, which may be used in combination with any other aspect recited herein, unless stated otherwise, the method comprises, through a processor, at least one of the fields comparing at least some of the text from at least one of the fields to a predetermined range; writing at least a portion of the text from at least one of the text.

According to a seventeenth aspect of the disclosure, which may be used in combination with any other aspect listed herein, unless otherwise stated, a system for transmitting information to a patient comprises: transmitting treatment information; A patient's home therapy machine configured to do so, a medical record, and an application that identifies the home therapy machine and the patient's personal device as a registered device and allows the personal device to view treatment and medical information. a clinician database configured to store a registration file and a clinician database configured to store a registration file; The system also includes a clinician database, a home therapy machine, and a clinician server communicatively coupled to the personal device. The clinician server stores treatment and medical information in the medical record, receives instructions that at least a portion of the treatment and medical information should be displayed on the personal device, and receives instructions from the registration file that the application configured to determine whether it is installed on a personal device; If the application is installed, the clinician server converts at least some of the treatment information and medical information to an application format for display within the application, and converts at least a portion of the treatment information and medical information to an application format for display within the application. and configured to transmit at least a portion to a personal device. If the application is not installed, the clinician server converts at least some of the treatment information and medical information into text message or Short Messaging Service ("SMS") format and sends one or more text or SMS messages to is configured to transmit the transformed at least a portion of the treatment information and medical information to the personal device via the personal device.

According to an eighteenth aspect of the present disclosure, which may be used in combination with any other aspect recited herein, unless stated otherwise, the application format is an Extensible Markup Language ("XML") format or including at least one of the following Hypertext Markup Language ("HTML") formats.

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

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

According to a twenty-first aspect of the disclosure, which may be used in combination with any other aspect listed herein, unless otherwise stated, the home therapy machine stores prescriptions using two programs. configured such that each of the programs provides parameters for operating the home therapy machine to perform the treatment, and the clinician server provides program messages indicating changes from the first program to the second program. from the personal device and transmitting program instructions for changing from the first program to the second program to the home therapy machine.

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

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

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

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

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

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

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

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

Additionally, it is an advantage of the present disclosure to reduce wastage of disposable sets and other auxiliary textile products due to disposal, which often occurs when mechanical timers expire.

The advantages discussed herein may be found in one or some, and perhaps not all, of the embodiments disclosed herein. Additional features and advantages are described herein and will be apparent from the detailed description and figures below.
The present invention further provides, for example, the following.
(Item 1)
A machine-accessible device storing instructions, the instructions being configured, when executed, to cause the machine to populate a patient medical record of a clinical system, the instructions comprising: Inputting data is
Operating the camera and recording images;
operating a display interface;
operating a connection interface configured to connect to a clinician database, the clinician database configured to store patient medical records;
To operate the processor and obtain medical information.
According to
Obtaining the medical information includes:
displaying, via the display interface, a user interface with fields to be populated with medical information;
After selection of a data field in the user interface, a first option for inputting medical information from an image and a second option for inputting medical information via text input are displayed graphically via the display interface. to provide the
If the first option is selected,
receiving a recorded image from the camera, the recorded image comprising a medical device or a screen of a medical device;
extracting text from the image;
enabling selection of at least a portion of the text from the image via the display interface;
writing the selected text from the image as the medical information into the data field of the user interface;
and
if the second option is selected, enabling text entry of the data field as the medical information via the display interface;
transmitting the medical information written in the data field to a patient medical record stored in the clinician database after a transmission command is received;
Machine-accessible devices by.
(Item 2)
further comprising instructions stored on the machine-accessible device, the instructions being configured, when executed, to cause the machine to operate the processor;
determining a data template for the extracted text on the image;
processing the extracted text using the data template and classifying the extracted text into fields;
enabling selection of at least one of the fields and writing the selected text from the image to the data field of the user interface;
Machine-accessible device according to item 1.
(Item 3)
3. The machine-accessible device of item 2, wherein the data template is configured to define a context for the extracted text in relation to text position within the image.
(Item 4)
further comprising instructions stored on the machine-accessible device, wherein the instructions, when executed, are configured to cause the machine to operate the processor, the processor (i) providing medical care via the user interface; selection of a device type; (ii) information scanned from an identifier located on the medical device; and (iii) at least one of an indicator in the extracted text; or (iv) the 3. The machine-accessible device of item 2, wherein the data template is determined based on relative placement of extracted text.
(Item 5)
The identifier located on the medical device may be a quick response (“QR”) code, bar code, serial number, or hardware located on the housing of the medical device or on the screen of the medical device. The machine-accessible device of item 4, comprising at least one of the numbers.
(Item 6)
The machine-accessible device of item 1, wherein the medical device includes at least a renal failure therapy machine, an infusion pump, an oxygen sensor, a respiration monitor, a glucose meter, a blood pressure monitor, an ECG monitor, a weight scale, and a heart rate monitor.
(Item 7)
The data field of the user interface stores at least one of blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual replacement data, subjective data, or consumable data regarding a consumable item. The machine-accessible device of item 1, configured to receive.
(Item 8)
Item 7, wherein the consumable item includes at least one of a filter, a blood line set, a dialysate concentrate container, a blood anticoagulant container, a drug container, a disposable cassette, a sorbent cartridge, and a water purification container. Machine-accessible devices as described.
(Item 9)
The machine-accessible device of item 1, wherein the machine is a personal mobile communications device.
(Item 10)
A method of populating a patient medical record in a clinical database using recorded images, the method comprising:
transmitting a first message to a personal device, the first message prompting the patient to record a first image of the medical device using a camera of the personal device; ,
receiving the first image from the personal device;
determining, via a processor, first medical information from the first image indicating a type or model of the medical device;
determining, via the processor, a data template and a second message associated with the determined type or model of the medical device;
transmitting, via the processor, the second message to the personal device, the second message configured to record a second image of a screen of the medical device using the camera; prompting said patient to;
receiving the second image from the personal device via the processor;
extracting text from the second image via the processor;
processing the extracted text using the data template via the processor and classifying the extracted text into fields;
writing, via the processor, at least a portion of the text from at least one of the fields to the patient medical record;
including methods.
(Item 11)
determining, via the processor, a correspondence between one of the fields and a record field within the patient medical record;
writing, via the processor, the at least a portion of the text from the field to the record field in the patient medical record;
The method according to item 10, further comprising:
(Item 12)
determining a treatment time from the patient medical record via the processor;
transmitting the first message via the processor before the treatment time;
The method according to item 10, further comprising:
(Item 13)
receiving, at the processor, a treatment message from the personal device indicating that the patient should begin treatment;
transmitting the first message via the processor before the treatment is initiated;
The method according to item 10, further comprising:
(Item 14)
The first image is received at the processor via a first text message or a first Short Messaging Service (“SMS”) message, and the second image is received in a second text message or a second short messaging service (“SMS”) message. 11. The method of item 10, wherein the method is received at the processor via an SMS message.
(Item 15)
further comprising converting, via the processor, the at least a portion of the text from the at least one of the fields to a Health Level 7 (“HL7”) format prior to writing to the patient medical record. , the method described in item 10.
(Item 16)
comparing, via the processor, the at least a portion of the text from at least one of the fields to a predetermined range;
via the processor: if the at least a portion of the text from at least one of the fields is within the predetermined range; writing at least a portion of said
The method according to item 10, further comprising:
(Item 17)
A system for transmitting information to a patient, the system comprising:
the patient's home therapy machine configured to transmit treatment information;
a clinician database configured to store the medical record and a registration file, the registration file identifying the home therapy machine and the patient's personal device as a registered device; a clinician database identifying whether the treatment information and an application for viewing the medical information are installed;
a clinician server communicatively coupled to the clinician database, the home therapy machine, and the personal device;
Equipped with
The clinician server includes:
storing the treatment information and the medical information in the medical record;
receiving an indication that at least a portion of the treatment information and the medical information should be displayed on the personal device;
determining from the registration file whether the application is installed on the personal device;
If the said application is installed,
converting the at least a portion of the treatment information and the medical information into an application format for display within the application;
transmitting the transformed at least a portion of the treatment information and the medical information to the personal device;
and
If the above application is not installed,
converting the treatment information and the at least a portion of the medical information into a text message or short messaging service (“SMS”) format;
transmitting the treatment information and the transformed at least a portion of the medical information to the personal device via one or more text messages or SMS messages;
and
A system that is configured to:
(Item 18)
18. The system of item 17, wherein the application format includes at least one of an Extensible Markup Language ("XML") format or a Hypertext Markup Language ("HTML") format.
(Item 19)
The indication that at least a portion of the treatment information and the medical information should be displayed on the personal device is at least one of a message from the application or a text/SMS message from the personal device. The system according to item 17, comprising:
(Item 20)
18. The system of item 17, wherein the registration file is included within the medical record.
(Item 21)
The home therapy machine is configured to store prescriptions using two programs, each of the programs providing parameters for operating the home therapy machine to administer a treatment, and each of the programs providing parameters for operating the home therapy machine to administer a treatment. The server is
receiving a program message from the personal device indicating a change from a first program to a second program;
transmitting program instructions to the home therapy machine for changing from the first program to the second program;
18. The system of item 17, wherein the system is configured to perform.

FIG. 1 illustrates one embodiment of a medical fluid data transfer system that incorporates a medical fluid delivery machine of the present disclosure so that data may be transferred to and from such machine, according to an embodiment of the present disclosure. It is a schematic diagram.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

23 and 24 illustrate the medical device of FIG. 21 using images recorded by the personal mobile communication device of FIGS. 10 and 11 (and/or text messages received therefrom), according to certain exemplary embodiments of the present disclosure. FIG. 2 is a flow diagram of an example procedure for populating a template. 23 and 24 illustrate the medical device of FIG. 21 using images recorded by the personal mobile communication device of FIGS. 10 and 11 (and/or text messages received therefrom), according to certain exemplary embodiments of the present disclosure. FIG. 2 is a flow diagram of an example procedure for populating a template.

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

26-29 depict schematic diagrams of a personal mobile communication device displaying medical information provided by the clinician server of FIGS. 10 and 11, according to an exemplary embodiment of the present disclosure. 26-29 depict schematic diagrams of a personal mobile communication device displaying medical information provided by the clinician server of FIGS. 10 and 11, according to an exemplary embodiment of the present disclosure. 26-29 depict schematic diagrams of a personal mobile communication device displaying medical information provided by the clinician server of FIGS. 10 and 11, according to an exemplary embodiment of the present disclosure. 26-29 depict schematic diagrams of a personal mobile communication device displaying medical information provided by the clinician server of FIGS. 10 and 11, according to an exemplary embodiment of the present disclosure.

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

FIG. 31 depicts a schematic diagram of the personal mobile communication device of FIGS. 10 and 11 providing a program regarding a medical treatment to select to a patient, according to an exemplary embodiment of the present disclosure.

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

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

A medical fluid delivery system is disclosed herein. Exemplary medical fluid delivery systems are configured to improve patient engagement with medical treatments, such as medical fluid delivery treatments. Medical fluid delivery systems provide patients with greater transparency and at least some control over their own treatment, while providing resources to educate or otherwise assist the patient throughout the treatment process. configured to provide. The exemplary medical fluid delivery system is configured to provide patient engagement regardless of the type or set of characteristics of the medical device or patient's personal mobile communication device involved in the treatment. Such a configuration allows the disclosed medical fluid delivery system to be compatible with virtually any patient situation.

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

As disclosed herein, an exemplary clinician server receives medical fluid delivery data (e.g., treatment information) from a medical fluid delivery machine, and the delivery data is associated with one or more patients in a clinician database. recorded in the record. The clinician server provides personal mobile communication devices with access to medical fluid delivery data and allows patients to track treatment progress. In addition, a patient may use a personal mobile communication device to change a treatment program (or request that a treatment program be changed). The request is routed through the clinician server to verify that the changes are appropriate before being transmitted to the medical fluid delivery machine.

An exemplary clinician server operates in conjunction with a personal mobile communication device to enable patients to effortlessly provide medical information such as vital sign data, medical device data, and the like. Personal mobile communication devices allow patients to manually enter data, record photographs, and/or retrieve data from connected medical devices such as scales, blood pressure monitors, thermometers, glucose meters, etc. configured to enable wireless reception. The data collected is stored in the patient's medical record. In some embodiments, the clinician server and/or personal mobile communications device may use the template to determine how received data should be automatically populated into the patient's medical record.

As disclosed herein, personal mobile communication devices may include feature-rich smart devices such as smartphones or tablet computers. A smart device may operate specialized applications (eg, "apps") defined by instructions stored in memory. Execution of the stored instructions causes the smart device's processes to operate the application, where the application is configured to improve patient engagement in medical treatment. In some cases, personal mobile communication devices may include traditional cellular telephones with fewer features, including significantly less processing power and features compared to smart devices. Cellular devices may operate using specialized applications (eg, apps) defined by text messages and/or instructions stored in memory. Applications for devices with fewer features may have fewer features compared to applications for smart devices.

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

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

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

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

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

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

Most HD (HF, HDF) treatments are performed in centers. The trend toward home hemodialysis (“HHD”) is due in part to the fact that HHD can be performed daily and offers therapeutic benefits over in-center hemodialysis treatments (typically performed two or three times a week). It exists today because it provides. Studies have shown that frequent treatments remove more toxins and waste than patients who receive less frequent, but perhaps longer, treatments. Patients who are treated more frequently do not suffer as many down cycles as in-center patients who accumulate two or three days' worth of toxins prior to treatment. In some regions, the nearest dialysis center may be many miles from a patient's home, leading to door-to-door treatment times that take up a large portion of the day. HHD may be performed overnight or during the day while the patient is relaxing, working, or otherwise productive.

Another type of kidney failure treatment is peritoneal dialysis, in which dialysate, also called dialysis fluid, is injected into the patient's peritoneal cavity through a catheter. The dialysis fluid contacts the peritoneum of the peritoneal cavity. Waste products, toxins, and excess water flow from the patient's bloodstream, through the peritoneum, and into the dialysis fluid due to diffusion and osmosis; ie, an osmotic gradient occurs across the membrane. Osmotic agents in dialysis provide an osmotic gradient. The used or depleted dialysis fluid is drained from the patient, removing waste, toxins, and excess fluid from the patient. This cycle is repeated, for example, multiple times.

Various types of peritoneal dialysis treatments exist, including continuous ambulatory peritoneal dialysis ("CAPD"), automated peritoneal dialysis ("APD"), and tidal flow dialysis, and continuous flow peritoneal dialysis ("CFPD"). CAPD is a manual dialysis treatment. Here, the patient manually connects the implanted catheter to the drain to allow used or depleted dialysate fluid to drain from the peritoneal cavity. The patient then connects the catheter to a bag of fresh dialysis fluid to infuse fresh dialysis fluid into the patient through the catheter. The patient disconnects the catheter from the fresh dialysis fluid bag, allowing dialysis fluid to reside within the peritoneal cavity, and transport of waste, toxins, and excess fluid occurs. After a certain dwell period, the patient repeats the manual dialysis procedure, for example, four times per day, with each treatment lasting approximately one hour. Manual peritoneal dialysis requires a significant amount of time and effort from the patient, and there is room for improvement.

Automated peritoneal dialysis (“APD”) is similar to CAPD in that the dialysis treatment includes drain, fill, and dwell cycles. However, APD machines typically perform cycles automatically while the patient is asleep. APD machines free patients from the need to manually perform treatment cycles and from the need to transport supplies during the day. The APD machine fluidly connects to an implanted catheter, a source or bag of fresh dialysis fluid, and a fluid drain. APD machines pump fresh dialysis fluid from a dialysis fluid source through a catheter and into the patient's peritoneal cavity. APD machines also allow dialysis fluid to reside within the cavity, allowing transport of waste, toxins, and excess water to occur. The source may include a plurality of sterile dialysis fluid bags.

APD machines pump used or depleted dialysate from the peritoneal cavity, through a catheter, and into a drain. As a manual process, several drain, fill, and dwell cycles occur during dialysis. The "final fill" occurs at the end of the APD and remains within the patient's peritoneal cavity until the next treatment.

Any of the above machine-implemented modalities may be performed on a scheduled basis and may require a startup procedure. For example, dialysis patients typically undergo treatment on an alternate-day, daily, etc. schedule. Blood treatment machines typically require a certain amount of time prior to treatment, for example, for setup to perform disinfection procedures. Patients with the above modalities may lead busy lives and have plans or errands to perform on the day the treatment is scheduled.

Much of the appeal of home treatment for patients revolves around the lifestyle flexibility provided by allowing patients to carry out treatment primarily at home according to their own schedule. However, the home medical fluid delivery machine may include a software timer to instruct and constrain the user or patient. Home hemodialysis systems may require the patient to be in close proximity to the home hemodialysis machine, for example, to initiate pre-, during-, and post-therapy sequences.

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

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

In one embodiment, the system of the present disclosure provides a software application (“app”) that is installed on a patient and/or caregiver's personal mobile communication device, such as a smartphone. Apps, in one embodiment, are provided via middleware software applications, examples of which are discussed in detail below. In an alternative embodiment, the software is configured to communicate with a patient and/or caregiver's personal mobile communication device, such as a smartphone, directly using text messaging features through a middleware software application. In either case, the app or text message, in one embodiment, can remind the patient of any impending deadlines, without tethering the patient to a machine, so that the patient and/or caregiver knows when treatment needs to begin. Built to allow you to track when.

Alternatively, or in addition, it is envisaged that the communication software be constructed to automatically program reminders on the user's mobile communication device, eg, on the device's inherent task tracking features, such as a calendar application. Most smartphones are provided with a calendar that separates each day into time segments, such as hours. The software of the systems and methodologies of the present disclosure accesses the authorized patient and/or caregiver's smartphone calendar and provides the appropriate information for the appropriate time segment on the appropriate day, e.g., if the machine disinfects during that time segment. It can be programmed to initiate or complete.

In one embodiment, communication from the software systems and methodologies of this disclosure is unidirectional. For example, the communication may be from a medical fluid delivery machine, which may be a home machine, to a patient or caregiver's mobile communication device. In an alternative embodiment, the software systems and methodologies of the present disclosure enable two-way communication between a medical fluid delivery machine and a patient or caregiver's mobile communication device. In one example, two-way communication may allow certain machine routines to be initiated remotely by patients or caregivers using their mobile communication devices. One example routine is an automated self-test routine, which may be performed without any user interaction with the system other than initiating or initiating a sequence. Initiating a sequence remotely may benefit the patient or caregiver, for example, by providing additional time for the patient or caregiver to be away from the machine to perform other tasks. Communication is bi-directional once the machine begins communicating by indicating that it is ready to perform a self-test routine. The patient or caregiver responds to the machine at the desired time and initiates the sequence via the software system and methodology of the present disclosure.

It is envisioned that the software of the disclosed systems and methodologies will disable communication between the patient and/or caregiver and the machine whenever the machine is in the "patient connected" software state. For example, if a clinician attempts to send a command to a machine that is currently treating a patient, the command may be blocked by the middleware software application so that the command is not forwarded to that machine. The middleware software application may then reply to the clinician, informing him that the machine is busy and will not accept communications.

The examples described herein are applicable to any medical fluid delivery system that delivers medical fluids such as blood, dialysis fluid, substitute fluids, and/or intravenous drugs (“IV”). Examples include, inter alia, all forms of hemodialysis (“HD”), hemofiltration (“HF”), hemodiafiltration ( It is highly suitable for renal failure treatments such as "HDF"), continuous renal replacement therapy ("CRRT"), and peritoneal dialysis ("PD"). The medical fluid delivery machine may alternatively be a drug delivery or nutritional fluid delivery device, such as a high volume peristaltic type pump or a syringe pump. The machines described herein can be used in home settings. For example, a machine operating in the data transfer mode of the present disclosure may be employed with a home HD machine that may be activated at night while the patient is sleeping, for example. The medical fluid data transfer systems and methodologies of the present disclosure may alternatively be used to assist clinicians or nurses in hospitals and/or clinics.

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

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

Home treatment machine 90 may receive purified water at its front end from water treatment device 60 as discussed above. Water treatment device 60, in some embodiments, connects to home treatment machine 90 via an Ethernet cable. The home treatment machine 90 in the illustrated embodiment operates with other devices other than the water treatment device 60, such as a blood pressure monitor 104, a meter, e.g., a wireless meter 106, and a user interface, such as a wireless tablet user interface 122. . Home therapy machine 90, in one embodiment, connects wirelessly to server 118 via modem 102. Each of these components may (though need not) be located within the patient's home, as delimited by the dashed line in FIG. 1 . Any one, two or more, or all of components 60, 104, 106, and 122 may communicate with home therapy machine 90 by wire or wirelessly. The wireless communication may be Bluetooth®, WiFi®, Zigbee®, Z-Wave®, wireless Universal Serial Bus (“USB”), infrared, or any other suitable wireless It can be through communication technology. Alternatively, any one, two or more, or all of components 60, 104, 106, and 122 may communicate with home therapy machine 90 via wired communications.

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

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

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

In one embodiment, the home treatment machine 90 provides home treatment, such as home hemodialysis, to a patient in the patient's home and is then used by clinicians, physicians, and nurses involved in managing the health and well-being of that patient. Report the results of the treatment to your doctor.

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

In one embodiment, home therapy machine 90 uses a connectivity service to transfer data between modem 102 and system hub 120, such as over the Internet. Here, a dedicated line may be provided at each patient's home to connect home therapy machine 90 to connection server 118 via modem 102. Home therapy machine 90 in one embodiment uses a separate, eg, 3G, 4G, or 5G modem 102 to access the Internet. 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 (eg, the provider of connectivity server 118) is installed on home therapy machine 90 and activated on the machine's ACPU 50. One suitable connectivity service is provided by Axeda®, which provides a securely managed connection 116 between a medical device and a connectivity server 118.

Connection agent 114 enables home therapy machine 90 to connect to connection server 118 and transfer data to and from connection server 118. Connectivity services operating through agent 114 and server 118 ensure that the connection with machine 90 is secure, that data passes correctly through machine 90's firewall, and that there is no data or system crash. to ensure that the connection server 118 is communicating with the correct home therapy machine 90.

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

In the medical fluid data transfer system 10 of FIG. 1, connectivity services via a connectivity server 118 are provided via a system hub 120 to various locations such as a service portal 130, a clinic or hospital 126a-126n, and a web portal 150. May communicate data. Connection server 118 allows maintenance personnel 132a-132n and/or clinicians to connect various assets (such as appropriate home therapy machines 90 and 3G, 4G, or 5G modems 102) and their associated information (such as machine or modem serial number). Connection server 118 receives firmware upgrades approved by maintenance personnel supervisor 134 and obtained remotely via service portal 130 and transmits them to associated devices such as authorized home treatment machines 90 and water treatment devices 60. It can also be used to provide additional peripherals.

(A. Exemplary Medical Fluid Delivery Machine)
Referring now to FIG. 2, an example HD flow diagram for a medical fluid delivery machine 90 is illustrated. Because the HD system of FIG. 2 is relatively complex, FIG. 2 and its discussion are also suitable for any of the renal failure treatment modalities discussed above and for IV, drug delivery, or nutritional fluid delivery machines. Provide support. Generally, a medical fluid delivery machine 90 is shown having a simplified version of a dialysis fluid or process fluid delivery circuit. The blood circuit is also simplified, but not as much as the dialysis fluid circuit. The circuits have been simplified to facilitate explanation of the present disclosure, and the system, when implemented, may incorporate additional structure and functionality such as that found in the publications incorporated by reference above. It should be understood that there will be a

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

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 detect air within arterial and venous lines 14 and 16, respectively. If air is detected by one of air detectors 22a and 22v, system 10 closes line clamps 18a and 18v and suspends the blood and dialysis fluid pumps so that treatment can resume. Provide instructions to the patient to clear the air.

A blood pump 30 is located within the arterial line 14 in the illustrated embodiment. In the illustrated embodiment, blood pump 30 includes a first blood pump pod 30a and a second blood pump pod 30b. Blood pump pod 30a operates in conjunction with inlet valve 32i and outlet valve 32o. Blood pump pod 30b operates in conjunction with inlet valve 34i and outlet valve 34o. In certain embodiments, each of blood pump pods 30a and 30b is a blood container that includes, for example, a spherical rigid outer shell with a flexible diaphragm positioned within the shell to form a diaphragm pump. One side of each diaphragm receives blood while the other side of each diaphragm is operated by positive and negative air pressure. 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.

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

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

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

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

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

A fifth pod pump (not shown) provided in the exhaust line 82 is used to remove a known amount of ultrafiltration ("UF") when HD therapy is provided. System 10 tracks the UF pump to control and track the amount of ultrafiltrate removed from the patient. System 10 ensures that the required amount of ultrafiltrate is removed from the patient by the end of treatment.

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

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

FIG. 2 shows that before reaching hemofilter 40, dialysis fluid is pumped along fresh dialysis fluid line 76 through heater 78 and ultrafilter 80, and then used dialysis fluid is pumped through drain line 82. It is also shown that the water is pumped to be discharged. Heater 78 heats the dialysis fluid to body temperature or approximately 37°C. Ultrafilter 80 further cleans and decontaminates the dialysis fluid before it reaches hemofilter 40 and removes foreign matter and/or substances introduced from the dialysis fluid via, for example, bicarbonate cartridge 72 or acid reservoir 74. or filter contaminants.

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

In the illustrated embodiment, the medical fluid delivery machine 90 is a continuous series pass-through system in which the system pumps dialysis fluid once through a hemofilter and then pumps out the used dialysis fluid. Pressure feed as shown. Both blood circuit 20 and dialysis fluid circuit 70 can be hot water disinfected after each treatment so that blood circuit 20 and dialysis fluid circuit 70 can be reused. In one implementation, blood circuit 20, including hemofilter 40, is hot water disinfected and reused daily for about one month, while dialysis fluid circuit 70 is hot water disinfected and reused for about six months.

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

Medical fluid delivery machine 90 includes an enclosure as shown by the dashed line in FIG. The enclosure of the machine 90 depends on the type of treatment, whether the treatment is in-center or home treatment, and whether the dialysis fluid/infusate supply is batch-type (e.g., bagged) or direct-coupled. It changes accordingly.

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

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

B. Connectivity Embodiments of Exemplary Medical Fluid Delivery Systems
Referring now to FIG. 4, a system 110a of the present disclosure is illustrated. System 110a in the illustrated embodiment operates in conjunction with system 10 described above, which includes connection server 118, system hub 120, service portal 130, enterprise resource planning system 140, web portal 150, and business intelligence. including portal 160, which are illustrated in FIG. 4 as part of a cloud environment. Connection server 118, system hub 120, service portal 130, enterprise resource planning system 140, web portal 150, and business intelligence portal 160 are each part of a cloud environment or located on one or more dedicated servers. It is possible.

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

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

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

In another example, medical fluid delivery machine 90b may be preprogrammed to begin treatment at 3:00 p.m. Medical fluid delivery machine 90b may require three hours for self-testing and disinfection. Patient 12a or clinician 112a must therefore be at machine 90b by noon to begin pre-treatment. In some embodiments, the patient 12a or clinician 112a configures the machine 90b regarding how far in advance of the three hour preparation time the patient 12a or clinician 112a should be notified or alerted (e.g., two hours). . Thus, in this example, machine 90b may generate code at 10:00 AM and send the code to middleware software stored on system hub 120. The middleware software then converts the code, using a lookup table, for example, into a message such as "Begin treatment preparation in 2 hours" and sends it on the mobile communication device 200b of the patient 12b or clinician 112b. Display a message on the downloaded app. The app can again be programmed to provide a visual identifier along with the message, such as a countdown timer that counts down from 120 minutes to a timeout at zero. The app may also include one or more of an audio alert, such as a "ring" sound, and/or a tactile alert, such as a vibration, to prompt the patient 12b or clinician 112b to view the app and confirm treatment readiness notifications. can be provided. The app may also be programmed to repeat the "ring" sound and/or tactile feedback at preprogrammed intervals (eg, 1 hour, and 30 minutes) during the countdown period.

In addition to, or as an alternative to, providing an app on the user's communication device 200b, middleware software at the system hub 120 may send messages to the machine 90b that are embedded onto the device's 200 specific task tracking features, such as its calendar application. It is assumed that the code from . Most smartphone devices 200 are provided with a calendar that separates each day into time segments, such as hours, for example. Here, messages translated by the middleware software of system hub 120 may be programmed to access the calendar of authorized communication device 200b and populate the appropriate information at the appropriate time segment on the appropriate day. In the above example, for the appropriate day, the native calendar software application would have its 10:0:00 AM timeslot filled with a message such as "Begin treatment preparation in 2 hours." Audio and/or tactile feedback signals may be provided to notify patient 12 or clinician 112 about calendar entries.

Machines 90a and 90b, middleware software at central server 120, and communication devices 200a and 200b are configured as described above to provide any desired messages to patients 12a, 12b and/or clinicians 112a, 112b. It should be understood that the messages that may be programmed and operated are not limited to the messages described herein. For example, the patient 12a, 12b and/or the clinician 112a, 112b may also use an associated countdown timer to determine when the treatment is complete at the end of the disinfection to avoid the need to re-disinfect the machine 90a, 90b. You may be informed that it needs to be started within a countdown time.

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

System hub 120 in one embodiment implements middleware software that can be accessed by mobile communication device 200 (shown as a single device for ease of reference, but multiple devices 200 may be connected to system 110b as well). Remember. Mobile communication device 200 of FIG. 5 includes all of the structure, functionality, and alternatives disclosed with respect to devices 200a and 200b illustrated in FIG. 4 (including being connected to the Internet 52). In FIG. 5, mobile communication devices 200 download software applications (“apps”) from middleware software stored on system hub 120 via their connection to the Internet 52, although they do not have to. It is possible. The app may be operated exactly as described above in connection with FIG. 4 (including middleware software that converts encoded messages from the machine 90 into a format that can be presented on the app). Alternatively, or in addition, middleware software stored on system hub 120 can track native task tracking features of mobile communication device 200, such as its calendar application, in any of the ways described in FIG. It may be possible to convert the code from machine 90 into an embedded message.

Further alternatively or in addition, system 110b includes a cellular network 210 that interfaces between middleware software stored on system hub 120 and mobile communication device 200, for example. Cellular network 210 may include a network of cellular telephone towers that operate using radio waves and/or may employ satellites. Communication protocols suitable for use with the cellular network 210 of system 110b include (i) the "Worldwide Interoperability for Microwave Access" ("WiMAX") protocol and (ii) the may be a long-range protocol, such as the Global System for Mobile Telephony (GSM) protocol, which is a wide range of long-range wireless protocols that allow for data communications. The network 210 may alternatively or additionally be an IEEE 802.11a, (ii) IEEE 802.11b, (iii) WEE 802.11g, or (iv) 802.11n standard. A medium-range protocol may be employed, such as a wireless local area network ("WLAN"), which may be a protocol that is part of the International Association for the Advancement of Technology ("IEEE") 802.11 standard. Other suitable cellular technologies include CDMA, AMPS (Analog), General Packet Radio Service ("GPRS"), cdmaOne, CDMA2000, Evolution Data Optimized ("EV-DO"), GSM Evolved High Speed Data Rate (“EDGE”), Universal Mobile Telecommunications System (“UMTS”), Digital Cordless Telephone Standard (“DECT”), Digital AMPS (“IS-136/TDMA”), and Integrated Digital Enhancement Network (“iDEN”). may be included.

Mobile communication device 200 communicates with cellular network 210 via any of the methods known to those skilled in the art, such as via Short Messaging Service (“SMS”) or Multimedia Messaging Service (“MMS”) protocols. connect. Middleware software at system hub 120 may communicate with cellular network 210 in several ways. In one example, the phone number and carrier of the user 12, 112 (any or all of the patient 12, the patient's home care partner, the patient's clinician 112) may be identified, e.g., via a lookup table in middleware software. machine 90. When a message/code from a particular machine 90 is received by the middleware, the middleware software sends the email to [user phone number]@[carrier]. can be programmed to send to the net. For example, if patient 001's phone number is (555) 555-5555 and patient 001's carrier is AT&T, then when patient 001's machine 90 sends a message to the system hub 120's middleware software, it receives When the middleware software 120 sends the email to 5555555555@att. net, which is received by patient 001's mobile communication device 200 as a text message. Those skilled in the art will understand that there are multiple websites dedicated to telling you how to send email to text messages and outlining the details required by different carriers.

The middleware software stores each of the phone numbers of each of the mobile communication devices 200 and matches each of those numbers to the machine 90. When the event code is sent from the machine 90 to the middleware software as described above, the middleware software finds the telephone number of the mobile communication device 200 associated with that machine, e.g., as described above. Convert the code to the appropriate message using a lookup table like ``Setup'' and send the converted message to the called phone number. It is envisioned that multiple communication devices 200 may be associated with the same medical fluid delivery machine 90. For example, multiple doctor, nurse, and/or clinician telephone numbers may be associated with the same machine 90 at any of the clinics 126a-126n. In a home environment, the phone numbers of the patient 12 and the patient's clinician and/or caregiver assistant may be associated with the same machine 90.

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

The cellular message may convey information regarding any of the same events discussed above with respect to the software app and calendar update mode that populates the mobile communication device 200 with information. For example, medical fluid delivery machine 90 may have just completed its automated self-test routine and is now ready to perform a disinfection procedure. Machine 90 may generate a code identifying this condition and send it to middleware software stored on system hub 120. The middleware software then converts the code into a message such as "Self-test complete, ready to disinfect" using, for example, a look-up table, and sends the text message to the cellular output routine discussed above for the patient 12. or cause the clinician's 112 mobile communication device 200 to transmit and display the message. In an alternative embodiment, no code is required and the machine 90 instead sends the actual text string and the middleware software sends it as a text message, e.g., via the cellular output routine discussed above. Transfer it to mobile communication device 200. As is known, receipt of a text message on the communication device 200 may include an audio, e.g., "ring" sound and/or tactile alert, such as a vibration, prompting the patient 12 or clinician 112 to view the message. It can be accompanied.

In another example, medical fluid delivery machine 90 may be preprogrammed to begin treatment at 3:00 p.m. Medical fluid delivery machine 90 may again require three hours for self-testing and disinfection. The patient 12 or clinician 112 must therefore be at the machine 90 by noon to begin pre-treatment. In some embodiments, the patient 12 or clinician 112 configures the machine 90 as to how far in advance of the three hour preparation time the patient 12 or clinician 112 should be notified or alerted (e.g., two hours). . Here, machine 90 generates code at 10:00 AM and sends the code to middleware software stored on system hub 120. The middleware software then converts the code into a message such as "Please begin treatment preparation in 2 hours" using a lookup table, for example, and sends a text message to the cellular output routine discussed above, for example. to the mobile communication device 200 of the patient 12 or clinician 112, e.g., along with an audio alert, such as a "ring" sound, and/or a tactile alert, such as a vibration, prompting the patient 12 or clinician 112 to view the notification. Display a message.

Machine 90, middleware software at central server 120, and communication device 200 may alternatively or additionally use cellular network 210 to provide any desired messages to patient 12 and/or clinician 112. It should be understood that it may be programmed and operated as described above. For example, the patient 12 and/or the clinician 112 may also be informed at the end of disinfection that treatment must begin within a countdown time to avoid the need to re-disinfect the machine 90. obtain. It should also be appreciated that updating specific task tracking features, such as a calendar application, of communication device 200 may occur via an Internet connection or via cellular network 210 as illustrated in FIG. 5.

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

System hub 120 in one embodiment implements middleware software that can be accessed by mobile communication device 200 (shown as a single device for ease of reference, but multiple devices 200 may be connected to system 110b as well). Remember. Mobile communication device 200 of FIG. 6 includes all of the structure, functionality, and alternatives disclosed with respect to devices 200a and 200b illustrated in FIG. 4 (including being connected to the Internet 52). In FIG. 6, mobile communication devices 200 download software applications (“apps”) from middleware software stored on system hub 120 via their connection to the Internet 52, although they do not have to. It is possible. The app may be operated exactly as described above in connection with FIG. 4 (including middleware software that converts encoded messages from the machine 90 into a format that can be presented on the app). Alternatively, or in addition, middleware software stored on system hub 120 can track native task tracking features of mobile communication device 200, such as its calendar application, in any of the ways described in FIG. It may be possible to convert the code from machine 90 into an embedded message. The calendar application may alternatively be updated via the cellular network 210 discussed above in connection with FIG. 5 (alternatively illustrated via a dashed leader line in FIG. 6).

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

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

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

In another example, it may be desirable for machine 90 to automatically perform a self-test routine at some preset time before therapy is set to begin. Machine 90 notifies patient 12 or clinician 112 when it is time to begin disinfection. Here, connection agent 114 may be disconnected when patient 12 or clinician 112 initiates machine disinfection. In a further example, it may be desirable for machine 90 to notify patient 12 when disinfection is complete so that the patient begins treatment within a certain amount of time from the end of disinfection and disinfection does not need to be repeated. . Here, the connection agent 114 disconnects when the patient 12 or clinician 112 begins treatment, e.g., at the beginning of priming, when the patient is not already connected to a treatment line, e.g., arterial line 14 or venous line 16. can be done.

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

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

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

In step 3, the custom app downloaded to the patient's mobile communication device 200 communicates via audio, visual and/or tactile alerts and associated messages that the patient's 12 machine 90 indicates that the patient The patient 12 is alerted that the automated self-test routine can begin. In step 4, patient 12 uses a custom app on mobile communication device 200 to confirm that machine 90 should initiate its automated self-test routine.

In step 5, the patient's mobile communication device 200 sends a message to the middleware software application at the system hub 120 confirming that the patient's machine 90 is desired to begin its automated self-test routine. In step 6, the middleware software application at system hub 120 sends (eg, converts and sends) a message to machine 90 indicating that patient 12 has confirmed that machine 90 will begin its automated self-test routine. At step 7, machine 90 initiates and performs its automated self-test routine.

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

With respect to systems 110a-110c, to select the types of notifications that users wish to receive on their devices 200, for example, via the app itself, via text messages, and/or via calendar notifications. It is envisioned that the app on the mobile communication device 200 will be programmed to be configurable by the user. System hub 120, in one embodiment, may send all notification types and mobile communication device 200 ignores communication types that the user has disabled. System hub 120 in another embodiment remembers the user's preferences and sends only information in the selected notification type.

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

Screen 232 illustrates that app 230 may monitor and, if desired, control multiple machines 90. In the illustrated embodiment, machines 90a-90n are each represented by a dedicated icon 190a-190n displayed on screen 232 of app 230. Icons 190a-190n in the illustrated embodiment are identical to those on which machines 90a-90n are ordered within clinics 126a-126c to aid in accommodating physician/nurse/clinician 112 on screens 232-236. Ordered above.

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

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

Middleware software in system hub 120 or local system hub 220 updates the status of each machine 90a-90n. The nurse, clinician, or physician 112 may determine the current status of each machine 90a-90n, e.g., "out of service," "self-test," "disinfection," or as illustrated in screen 234 of FIG. Icons 190a-190n may be selected at any time to confirm "Patient Under Treatment." Other status markers are also envisioned and may differ for different types of machines. The nurse, clinician, or physician 112 then selects "Pause," "Self Exam," "Disinfect," or "Treating Patient" to return to the home icons 190a-190n as illustrated in FIG. You can choose one of them.

As discussed above, it is envisioned that the connection agent 114 of each machine 90 will be turned off when the machine is activated, particularly when the patient 12 is connected to the machine. However, the connections of each machine 90a-90n of clinics 126a-126n such that middleware software at system hub 120 or local system hub 220 can receive a status change to "patient in treatment" from each machine 90a-90n. It is also envisioned that the agent 114 may be allowed to remain on until the end of disinfection. In addition, since each machine 90a-90n knows its scheduled treatment duration, the machine can send the scheduled duration to the middleware software, which then updates the status change for "patient in treatment". and the duration in the form of a countdown timer. Here, if the nurse, clinician, or physician 112 then selects "Patient Treating" in FIG. It is possible to confirm.

With respect to countdown timers, connection agent 114 enables machines 90a-90n to send time remaining data to system hub 120 so that app 230 can determine the actual time remaining for each machine 90 undergoing a timed process. It is assumed that the following can be displayed. App 230 anticipates alarms or other delays that machine 90 may experience. During an alarm situation, corresponding icons 190a-190f may display a message such as "alarm" or "safe mode." The nurse, clinician, or physician 112 may then select the countdown time of FIG. 9 to return to the home icons 190c, 190d, and 190h illustrated in FIG.

The nurse, clinician, or physician 112 may or may not enable to be visually, audibly, and/or haptically alerted to status changes regarding the machines 90a-90n. , the alert on/off icon 238 may be toggled. If the alert on/off icon 238 is toggled “on,” the app 230 on the mobile communication device 200 will issue a visual, audible, and/or tactile alert each time the machine status changes, e.g., (i) “ (ii) “Self-test completed,” (iii) “Disinfection started,” (iv) “Disinfection completed,” (v) “Treatment started,” and (vi) “Treatment completed.” Dew. In some embodiments, the code for (i)-(v) is transmitted via the machines 90a-90n through the securely managed connection 116, the connection server 118, and the system hub 120 or local system hub 220, and is sent to the middleware It is translated by the software and forwarded to app 230, which updates the appropriate icon 190. In various embodiments, "(vi) Treatment Complete" is (a) transmitted via the machine 90a-90n with the activated connection agent 114, or (b) an appropriate icon 190a- 190n countdown timer expires and if the connection agent 114 may still be off.

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

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

In one embodiment, when the self-test button 240a is selected, any machine 90a-90n that is capable of performing a self-test at that time has its corresponding icon 190a-190n highlighted. The nurse, clinician, or physician 112 selects any icon 190 associated with the machine 90 on which the nurse, clinician, or physician 112 desires to perform a self-test. The selected icon 190 may then turn into a "confirm" button that the nurse, clinician, or physician 112 must press again to cause the selected machine 90 to perform its self-test. The app 230 on the mobile communication device 200 then sends the corresponding self-test code to the middleware software at the system hub 120 or local system hub 220, and the middleware software converts the self-test code into a self-test initiation command, as appropriate. and the command is sent to the connection agent 114 of the selected machine 90 via a securely managed connection 116 through the connection server 118, and the connection agent 114 forwards the command to the machine's ACPU 50; The ACPU 50 sequentially starts a self-test.

In the illustrated embodiment, when the disinfection button 240b is selected, any machine 90a-90n that is capable of performing disinfection at that time has its corresponding icon 190a-190n highlighted. The nurse, clinician, or physician 112 selects any icon 190 associated with the machine 90 on which the nurse, clinician, or physician 112 desires to perform disinfection. The selected icon 190 may turn into a "confirm" button that the nurse, clinician, or physician 112 must press again to cause the selected machine 90 to perform its disinfection. The app 230 of the mobile communication device 200 then sends the corresponding disinfection code to middleware software at the system hub 120 or local system hub 220, which converts the disinfection code into a disinfection initiation command, as appropriate; The command is sent to the connection agent 114 of the selected machine 90 via a securely managed connection 116 through the connection server 118, and the agent 114 forwards the command to the machine's ACPU 50, which in turn , begin disinfection.

The procedures thus described for action button 240 may also be implemented in system 110c and for other machine commands that may vary depending on the type of machine 90. It is sufficiently safe for the clinic 126a to leave the connection agent 114 on during a treatment or portion of a treatment by one or more nurses, clinicians, or physicians 112 present at the clinic. It is also assumed that it is possible to determine the In such cases, the nurse, clinician, or physician 112 may control the during-treatment activities associated with the machine 90. For example, nurses, clinicians, and physicians 112 can receive and respond to alarms/alerts via app 230 on mobile connected device 200, start and stop pumps and other aspects of treatment, and perform disinfection. Starting and stopping, starting and stopping priming, etc.

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

In one embodiment, when the mobile communication device 200 transmits data to the system hub 120 or local system hub 220 for delivery to the machine 90, the data identifies the mobile communication device 200 that transmitted the data. A device 200 identifier is provided. 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, mobile communication device 200 identifier maintained for server 118; The connectivity server 118 knows, for each mobile communication device 200, which machines 90 should, e.g., receive the converted data and, e.g., sends the converted data to each associated communication device 200. . Connection server 118 may strip the mobile communication device 200 identifier from the data once it is delivered to machine 90 because it is no longer needed.

App 230, as described above, allows a nurse, clinician, or physician 112 to set up, monitor, and possibly control therapy at medical fluid delivery machine 90. It is envisaged to provide similar functionality via an app to the patient 12 or a caregiver for the patient 12 in the patient's home (dashed box in FIG. 1). The connectivity may be the same as shown in Figures 7-9. However, the setting is not a clinic 126a-126n, but instead is a home or other non-clinical location, such as a business or vacation location. Additionally, there is typically only a single machine 90, rather than multiple machines 90a-90n. However, it is possible that a single patient 12 may be treated via multiple machines 90, and each of the multiple machines 90 may be supported by an app as described herein. When the patient 12 is at home but away from the machine 90, the app provides useful information such as the amount of time left to begin or complete startup procedure tasks, disinfection procedures, or self-test routines. can be provided. As a patient is being treated by machine 90, the patient can view information on its user interface 122, which itself may be a tablet as illustrated in FIG. However, there may also be a caregiver, such as a spouse, friend, or home nurse, who assists the patient 12 at home during treatment. Caregivers can use the at-home app by receiving status updates, start-up procedure time remaining, disinfection time remaining, priming time remaining, treatment time remaining, information regarding whether patient 12 is connected to machine 90, alerts, alarms, etc. benefit from. The app in one embodiment requires the login and password associated with the patient to be entered before it can be downloaded to the caregiver's mobile communication device 200, so that only authorized persons can Can view treatment data or information.

(II. Patient Involvement Embodiment)
The exemplary medical fluid delivery data transfer system 10 disclosed above in connection with FIGS. 1-9 improves patient engagement in medical fluid delivery treatments such as dialysis treatments, renal failure treatments, and/or peritoneal treatments. It is configured as follows. FIG. 10 illustrates an example medical fluid data transfer system 1000 similar to medical fluid data transfer system 10 discussed in connection with FIGS. 1-9, according to an example embodiment of the present disclosure. The example medical fluid data transfer system 1000 (e.g., a mobile platform) provides features for controlling and reporting treatment-related information to patients that improves treatment transparency, and/or provides educational materials and/or It is configured to improve patient engagement and/or compliance with treatment by providing access to real-time assistance from a clinician.

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

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 may provide, for example, continuous cyclic peritoneal dialysis (“CCPD”), tidal flow automated peritoneal dialysis (“APD”), and continuous flow peritoneal dialysis (“CFPD”). Home therapy machine 90 may automatically perform drain, fill, and dwell cycles, typically while the patient is asleep.

A peritoneal dialysis dialysate may comprise a solution or mixture containing 0.5% to 10%, preferably 1.5% to 4.25% glucose (or more generally glucose). Peritoneal dialysis fluids may include, for example, Dianeal®, Physioneal®, Nutrineal®, and Extraneal® dialysates commercially available by the assignee of this disclosure. The dialysate may additionally or alternatively contain a percentage of icodextrin.

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

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

Exemplary blood pressure monitor 104 includes any device configured to measure blood pressure and/or pulse of a patient. For example, blood pressure monitor 104 may measure a patient's blood pressure before, during, and/or after renal failure therapy treatment. Blood pressure monitor 104 may display a digital value indicative of the patient's blood pressure. Alternatively, the blood pressure monitor 104 may display a physical scale with a dial aligned with numbers to indicate the measured blood pressure. In some embodiments, the blood pressure monitor 104 displays the data before, during, and/or after treatment in a separate window so that patient input is required to view all values as medical information is recorded. blood pressure values can be memorized. 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 tracking device.

In addition to obtaining medical information (e.g., medical device data) from medical devices 90, 104, and 106, example personal mobile communication device 200a also obtains medical information from patient and/or therapy consumable items 1006. It is possible. FIG. 10 shows, for example, renal failure therapy medical device filters, disposable cassettes, blood line sets, drug delivery line sets, and containers (e.g., dialysate concentrate containers, blood anticoagulant containers, drug containers, and/or water purification containers). 10 shows an example of a consumable item 1006 including a container. Consumable items 1006 may also include sorbent cartridges or any other disposable or material source for medical treatment. The consumable item may include an identifier 1008 configured to provide medical information in the form of consumable information or consumable data. For example, identifier 1008 may include information that identifies the type of consumable item, serial number, and/or characteristics of the consumable item. In some cases, consumable item 1006 may also include indicia that include medical information, such as chemical composition characteristics. A patient or clinician uses a personal mobile communication device 200a to record an image of the identifier 1008, an image of the indicia on the consumable item 1006, and/or an image of the consumable item 1006 itself for use during treatment. Document the substance.

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

Collectively, blood pressure monitor 104 and meter 106 are referred to as a medical device. Medical fluid data transfer system 1000 includes infusion pumps (e.g., syringe pumps, linear peristaltic pumps, high volume pumps (“LVP”), portable pumps, multichannel pumps), oxygen sensors, respiratory monitors, glucose meters, blood pressure monitors, It should be appreciated that additional medical devices may be included, such as an electrocardiogram (“ECG”) monitor, a scale, and/or a heart rate monitor. In other examples, medical fluid data transfer system 1000 may include fewer and/or integrated medical devices (eg, blood pressure monitor 104 integrated with home therapy machine 90).

In some embodiments, personal mobile communication device 200a is configured to record, display, and/or populate patient medical records with medical information or data. As disclosed herein, medical information or data includes medical device data and patient data, which is created by a medical device, a patient, and/or a consumable item used by the medical device. may refer to data or information generated by or otherwise related to. For example, medical information includes prescription or programming information used by a medical device to administer treatment. Medical information includes sensed data such as fluid pressure, flow rate, conductivity, concentration, temperature, and patient data. As provided herein, patient data (eg, vital signs data) includes sensed physiological information of the patient, such as the patient's blood pressure, weight, heart rate, etc. Medical information may also include subjective information, such as information regarding a patient's mood (eg, bored, tired, satisfied, excited, etc.). The medical information can be displayed on the screen of the medical device, provided by a physical dial or display on the medical device, or can be printed on attached signage or on the medical device. Thus, medical device data or medical information includes medical device settings, medical device readings, and/or patient readings.

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

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

As shown in FIG. 10, some of all of the medical devices 90, 104, and 106 may include an identifier 1012 configured to store a unique identification number. Identifier 1012 may encode, for example, an assigned device number, serial number, hardware number, model number, and/or device type of each medical device 90, 104, and 106. For example, the identifier 1012b of the home therapy machine 90 may store an assigned device number. Personal mobile communication device 200a reads identifier 1012b from the screen of machine 90, for example, to determine the medical device type for subsequent analysis and the identification of medical information within the recorded image. In some embodiments, identifier 1012 may more generally indicate a model or type of medical device. For example, identifier 1012c may indicate that device 106 is a scale and/or may indicate a model number of the scale.

Identifier 1012 may include, for example, machine-readable markings such as a bar code or quick response (“QR”) code. Identifier 1012 may also include human-readable text such as a serial number, asset number, or hardware number. In some embodiments, an identifier 1012, such as identifier 1012b shown for home therapy machine 90, may be printed on an article physically attached to the housing of each medical device 90, 104, and 106. Additionally or alternatively, the identifier 1012 may be displayed on the screen of some of all of the medical devices 90, 104, and 106. For example, a clinician may select a control interface to cause home therapy machine 90 to display a window with identifier 1012b on the screen. In yet other embodiments, the identifier 1012 may be included within a radio frequency ("RF") microchip, such as an RFID chip or an NFC chip.

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

As illustrated in FIG. 10, an example fluidic data transfer system 1000 uses a web portal (similar to the respective devices discussed in connection with FIGS. 1-9) to communicate with a personal mobile communication device 200a. 150, system hub 120, and clinician server 200b. Web portal 150, system hub 120, and/or clinician server 200b transmit medical information from a patient's medical record (stored within clinician database 1010) to personal mobile communication device 200a. Additionally, web portal 150, system hub 120, and/or clinician server 200b may provide personal mobile communication device 200a with access to educational materials or real-time help sessions with a clinician. The example web portal 150, system hub 120, and/or clinician server 200b may also be configured to enable the personal mobile communication device 200a to provide medical information for input into a patient's medical record. Ru.

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

In the illustrated example of FIG. 10, example personal mobile communication device 200a includes a processor 1016 in communication with a memory 1018 that stores instructions. At least some of the instructions define or define an application 1002 that, when executed by processor 1016, causes processor 1016 to provide features that improve patient engagement and/or compliance with therapy. Processor 1016 may include digital and analog circuits structured as microprocessors, application specific integrated circuits (“ASICs”), controllers, and the like. Memory 1018 includes volatile or non-volatile storage media. Additionally, memory 1018 may include any solid state or disk storage media.

As discussed in more detail below, features of application 1002 include displaying treatment progress information, controlling treatment programs initiated by home therapy machine 90, recording medical information, displaying educational materials, and/or Including initiating a help session with a clinician. Application 1002 may be feature-rich or feature-poor. The feature-rich application is configured for smartphones and takes advantage of the unique graphics, touch screen, and processing power of personal mobile communication device 200a. Applications with fewer features are configured to run on cellular phones with relatively less sophisticated graphics and reduced processing power. Cellular phones may not include a touch screen or may instead have a touch screen with limited capabilities.

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

The example clinician server 200b includes an application 1020, such as application 230 described in connection with FIGS. 1-9. Application 1020 is configured to communicate with personal mobile communication device 200a and provide improved patient engagement and/or compliance. In some embodiments, example application 1020 is configured to facilitate storage of medical information (recorded by personal mobile communication device 200a) into one or more patient records within database 1010. Application 1020 may use one or more interfaces to provide treatment progress data and/or medical information to application 1002 for display on display interface 1022 (e.g., a touch screen) on personal mobile communication device 200a. It may also include an application programming interface (“API”). Application 1020 at clinician server 200b may provide educational materials and/or facilitate communication sessions between personal mobile communication device 200a and clinician device 152 in response to requests from application 1002.

In some instances, application 1002 on personal mobile communication device 200a and/or application 1020 on clinician server 200b performs medical fluid data transfer that complies with Health Level 7 (“HL7”) standards (e.g., medical standards). The system 1000 is configured to convert or otherwise provide medical information to clinician databases 1010 of other devices within the system 1000. This conversion allows medical information to be stored in HL7 format regardless of the format in which it is entered into personal mobile communication device 200a. Application 1002 and/or application 1020 may operate as a network conduit to seamlessly propagate relevant medical information from a medical device to a patient medical record when gaps in network or device connectivity exist.

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

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

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

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

(A. Registration module embodiment)
The example registration module 1102 is configured to register the personal mobile communication device 200a and/or the home therapy machine 90 with the clinician server 200b and/or with the patient's medical record stored within the database 1010. The example registration module 1102 is configured to provide different types of registration, and it uses the data access module 1106 to determine how information should be displayed to the patient based on the type of device being registered. used by Additionally, data acquisition module 1104 determines how treatment and/or medical information should be obtained based on the registration information.

Registration module 1102 is configured to store registration information in a registration file stored within clinician database 1010. The registration file includes, for each patient or patient activation code (“PAC”), information indicating registered personal mobile communication devices 200a, information indicating registered home therapy machines 90, and/or. Instructions regarding whether application 1002 is installed on personal mobile communication device 200a may be defined. In some embodiments, the registration file (or information from the registration file) may be included within the patient's medical record.

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

If the patient is registering without downloading and/or installing application 1002, data acquisition module 1104 determines that data acquisition should be prompted or directed. For example, data acquisition module 1104 may transmit text messages and/or emails to registered personal mobile communication device 200a (if home therapy machine 90 is not registered) regarding certain medical and/or treatment information. The patient may be prompted. Information within the message specifies the data required from the patient. Although this remote guidance may be used for feature-poor personal mobile communication devices 200a, it may also be used for smartphones where the patient does not want to download or install the application 1002 on a feature-rich device. obtain.

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

FIG. 12 shows a diagram illustrating communications between the home therapy machine 90 of FIGS. 10 and 11, a personal mobile communication device 200a, and a clinician server 200b, according to an exemplary embodiment of the present disclosure. Initially, home therapy machine 90 is registered with clinician server 200b via registration module 1102 of FIG. 11. Otherwise, clinician server 200b would have no information regarding patient record data from home therapy machine 90 to be stored. In some embodiments, home therapy machine 90 is preprogrammed with destination address information for connection server 118, system hub 120, and/or clinician server 200b. The destination address may include an Internet Protocol ("IP") address and/or a Hypertext Transfer (or Transport) Protocol ("HTTP") address.

During setup, the patient (or clinician) enters a patient activation code (“PAC”) into the home therapy machine 90. The PAC is originally generated and stored on the clinician server 200b and provided to the patient when the patient receives the home therapy machine 90. The PAC may include a patient identifier or other code that is unique to the patient. Registration module 1102 at clinician server 200b stores the generated PAC in one or more patient records and/or registration files associated with the patient. After entering the PAC, home therapy machine 90 generates and transmits a message 1202 containing the PAC. The message may also include a hardware identifier for home therapy machine 90 and/or an IP address assigned to home therapy machine 90. Home therapy machine 90 transmits message 1202 to a preprogrammed address, in this case connection server 118. The example connection server 118 relays the message 1202 to the system hub 120, which routes the message to the clinician server 200b. Registration module 1102 at clinician server 200b uses the PAC to register home therapy machine 90 with the patient. Registration includes, for example, associating an identifier of home therapy machine 90 with a patient's patient medical record. Registration may also include clinician server 200b storing the IP address of home therapy machine 90 and allowing messages to be transmitted to home therapy machine 90. After registration, data acquisition module 1104 of clinician server 200b stores treatment information received from home therapy machine 90 in one or more medical records associated with the patient.

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

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

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

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

As mentioned above, in some embodiments, personal mobile communication device 200a may not include an application. In these embodiments, personal mobile communication device 200a may communicate with clinician server 200b via text messages or through a web browser. Thus, registration module 1102 of clinician server 200b may transmit a text message to personal mobile communication device 200a with a hyperlink to a database or web page to complete registration. Alternatively, the text message may include a prompt for the patient to respond with their PAC. Providing a PAC through any of these registration processes allows registration module 1102 to register personal mobile communication device 200a (e.g., phone number, hardware address, or IP address) with appropriate patient medical records and/or Enables association with registration files.

(B. Data acquisition module embodiment)
FIG. 12 also illustrates data communications between home therapy machine 90, personal mobile communication device 200a, and clinician server 200b. During operation, home therapy machine 90 generates treatment and status information (eg, medical information). As discussed above in connection with FIGS. 1-9, treatment information includes the volume of fluid injected, the amount of ultrafiltration ("UF") removed from the patient, and/or treatment time. . Status information includes alarm, alert, or diagnostic information. Before or after treatment, home therapy machine 90 generates one or more messages 1208 with medical information, which are transmitted to connection server 118. Connection server 118, in turn, routes message 1208 to system hub 120, which routes message 1208 to data acquisition module 1104 of clinician server 200b. Once received, data acquisition module 1104 stores the medical information in a designated section of the patient's medical record (eg, patient medical record 1302 of FIG. 13). Message 1208 may include the 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.

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

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

FIG. 13 illustrates an example patient data structure 1300 stored on the clinician database 1010 of FIG. 10, according to an example embodiment of the present disclosure. Patient data structure 1300 includes separate patient records for different patients. In the illustrated example, data structure 1300 includes patient medical record 1302 for a patient associated with identifier "DCM31913" and patient medical record 1304 for a patient associated with identifier "GAM41215." Data structure 1300 may include additional patient medical records.

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

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

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

The data received by the example data acquisition module 1104 varies based on the source. For example, therapy information received from home therapy machine 90 is generally structured. In other words, home therapy machine 90 is configured to transmit therapy information that is formatted for direct entry into one or more data fields of a patient's medical record. In some embodiments, home therapy machine 90 formats (or otherwise formats) a message for transmission through the API of data acquisition module 1104 for populating the appropriate data fields with therapy information. access more than one API). In contrast, medical information recorded by a patient's personal mobile communication device 200a may initially be unstructured for inclusion in the patient's medical record. As described in more detail below, different techniques may be used to process and/or format medical information for input into the medical record using the application 1002 of the personal mobile communication device 200a and/or the clinician server 200b. can be used by the data acquisition module 1104 of.

(1. Embodiment of manual input of medical information into application)
To receive the structured information, the example application 1002 of the personal mobile communication device 200a, in some embodiments, prompts the patient to indicate medical information required for entry into the patient medical record. configured to display. The example application 1002 may include routines or algorithms that define fields to be displayed to prompt for medical information from a patient. In some embodiments, the fields or screens on which the fields are displayed are arranged and/or ordered in relation to a medical fluid delivery treatment. The display of fields informs the patient regarding the medical information needed for the patient record.

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

In some embodiments, the patient may obtain other medical information wirelessly or record some medical information via images, but manually select some of the medical information at user interface 1400 or 1500. can be entered. In these configurations, application 1002 may be configured to allow the patient to select an information input source. The patient may manually enter medical information after selecting a manual source from a menu of available data entry methods, or by default.

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

In some embodiments, application 1002 may be configured to display user interfaces 1400 and 1500 at designed times. For example, application 1002 may include a calendar that includes times/days when treatments are scheduled. At a designed time (e.g., 5 minutes, 15 minutes, 30 minutes, etc.) prior to treatment, the example application 1002 causes a user interface 1400 to be displayed on the personal mobile communication device 200a to prompt the patient regarding blood pressure medical information. It is composed of A prompt informs the patient that a blood pressure measurement is required before treatment can begin. The patient accordingly uses blood pressure monitor 104 to take blood pressure measurements. The patient then enters the values of the measurements into the user interface 1400 before treatment begins.

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

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

User interface 1500 of FIG. 15 is displayed by application 1002 when a patient is scheduled to perform manual exchange therapy and/or when home therapy machine 90 is not registered with clinician server 200b. It is configured as follows. Manual renal failure exchange therapy involves the patient connecting a container of dialysis fluid to his or her peritoneal cavity for a residence time before allowing the used dialysis fluid to be drained without mechanical assistance. demand everything. For manual treatments, patients must enter their own manually exchanged medical information to enable their records to reflect accurate treatment information.

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

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

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

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

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

(2. Embodiment of wireless input of medical information to application)
In some embodiments, a patient may choose to enter medical information wirelessly on their personal mobile communication device 200a. The medical information may be transmitted via, for example, a Bluetooth® connection, a Zigbee® connection, a Z-Wave® connection, a wireless USB connection, a wireless RF connection, an NFC connection, an infrared connection, or any other suitable connection. It may be received at personal mobile communication device 200a via wireless communication technology. In some instances, a patient may need to wirelessly pair a personal mobile communication device 200a with a medical device, such as a blood pressure monitor 104 and/or a scale 106. In other embodiments, the patient activates a connectivity application (eg, an NFC application) that wirelessly reads medical information from the medical device.

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

In some embodiments, application 1002 is configured to allow a patient to establish a permanent or semi-permanent connection with a medical device. During a setup operation, application 1002 prompts the patient to select data fields from user interface 1400. After selection, application 1002 prompts the patient to select a paired wireless medical device (and/or select a data type from a menu associated with the medical device). A selection by the patient, for example, configures the application 1002 to automatically read medical information from the blood pressure monitor 104 as new medical information becomes available. In other words, application 1002 is configured to wirelessly and automatically access a telemedicine device, read certain medical information, and populate 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 otherwise pin blood pressure monitor 104 to determine whether new data is available. Application 1002 then loads new data into one or more of data fields 1402-1410 and automatically populates user interface 1400. Application 1002 then sends the medical information to data acquisition module 1104 of clinician server 200b to automatically update the patient's medical record.

(3. Embodiment of image input of medical information to application)
The example application 1002 on the personal mobile communication device 200a is configured to allow a patient to enter medical and/or treatment information by recording an image of the medical device or screen of the medical device. Ru. Personal mobile communication device 200a uses camera 1004 to record one or more images. Application 1002 uses optical character recognition ("OCR") to extract text from recorded images. The extracted text is populated into one or more data fields of the user interface of application 1002. The use of images may reduce data entry errors from patients or clinicians.

In some embodiments, application 1002 uses rules or data templates to identify text from images that may be selectable as relevant medical information for data fields. Otherwise, simply using OCR features will make all of the displayed text selectable. Therefore, the patient still needs to copy and paste text from the image into the data field. By comparison, a rule or data template may classify or identify text from an image as a field, which allows for easy or automatic selection by the patient for populating the data field of the user interface.

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

A data template defines or specifies data fields of certain medical information contained within an image. Generally, the image includes extracted text comprising medical information. In some cases, not all of the extracted medical information is needed or necessary. Instead, only certain medical information within the recorded image is needed for entry into a user interface or into data fields of a patient medical record. Relevant medical information or related medical information is medical device data that is identified or selected for input into data fields of the user interface of the application 1002 or, more generally, into a patient's medical record. or refers to medical information.

FIG. 16 illustrates a schematic diagram of a personal mobile communication device 200a for recording and processing images for medical information extraction, according to an exemplary embodiment of the present disclosure. The illustration of personal mobile communication device 200a is exemplary and some of the blocks may be combined, further divided, or removed. Additionally, in some embodiments, personal mobile communication device 200a, when executed by data processor 1602 (or more generally, processor 1016), causes application 1002 to process images to extract medical information. Additional blocks may be included, such as memory 1018 for storing instructions.

The example 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 contain information that prompts a clinician or patient (e.g., an operator) to record certain images. provide. Alternatively, data processor 1602 may initiate the image processing mode after the patient selects to enter medical information into one or more data fields of application 1002 using an image input method. After selecting an image input method, data processor 1602 is configured to obtain one or more images.

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

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

In some examples, the data processor 1602 of FIG. 16 is configured to display a camera message identifying the medical device to be recorded, a user interface window of the medical device, and/or an identifier on the medical device. Data processor 1602 may also display navigation messages that define a medical device user interface window for imaging. Additionally, data processor 1602 may display a reminder message if an image is not recorded within a predetermined period of time (eg, 5 minutes). The message may include text providing instructions and/or identifying the intended target for imaging. The message may also include instructions regarding how to navigate to certain user interface windows of the medical device using the medical device's control interface. The message may further include graphical elements, such as an exemplary illustration of the medical device for which the image is to be recorded, the consumable item, an identifier 1012, and/or a user interface window.

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

To record images, example data processor 1602 and image processor 1604 (more generally, processor 1016) provide operations for application 1002 associated with camera 1004. The patient provides instructions via camera user interface 1606 (eg, a touch screen or button on personal mobile communication device 200a) to record an image. The patient activates camera user interface 1606, for example, when the camera is focused on medical device user interface window or identifier 1012. Data processor 1602 receives instructions and instructs camera 1004 to record images. The recorded images are transmitted from camera 1004 to image processor 1604. Additionally, a copy of the image is displayed by data processor 1602 on display interface 1022 of personal mobile communication device 200a.

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

Data processor 1602 may provide a prompt to the patient to accept the image. After receiving an indication of acceptance via camera user interface 1606, image processor 1604 may analyze the image to identify or otherwise extract text. In some cases, data processor 1602 may not prompt the clinician to accept the image. Alternatively, the patient may provide instructions to delete the image via camera user interface 1606. Until the image is deleted, image processor 1604 performs analysis to identify text.

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

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

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

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

FIG. 17 illustrates a schematic diagram of a data template 1700, according to an example embodiment of the present disclosure. Exemplary data template 1700 is used by image processor 1604 (eg, application 1002) to identify extracted text as relevant medical information. Generally, the screen of a medical device displays medical information. Some of the information is relevant for inclusion within data fields of the user interface of application 1002. Others of the data may be less relevant or even non-relevant. Furthermore, depending on the model of the medical device, the medical information may be in different locations or have different labeling. Data template 1700 is configured to define the location and name of relevant medical information for a particular home therapy machine 90.

Data template 1700 is stored in database 1608 along with multiple other data templates regarding different types and/or models of medical devices and/or consumable items. After receiving a medical device identifier 1012 (or a patient's definition of a medical device or data field), 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 the recorded image using, for example, informational indicators or text locations.

The example data template 1700 of FIG. 17 includes device data (or text) fields 1702, 1704, 1706, and 1708 that define where certain medical information is located on a particular user interface window of a medical device. do. In some examples, data template 1700 is graphical such that image analysis is performed to align fields 1702-1708 with extracted text within the image. In other examples, data template 1700 includes a file (or other data structure) having coordinates or locations for each of device data fields 1702-1708 relative to an origin. Image processor 1604 identifies an origin in the image with extracted text and identifies the text for each of data fields 1702-1708 based on a substantial match to a location within data template 1700. In some examples, image processor 1604 may scale the image to match the size or coordinate space of data template 1700.

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

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

Indicator text associated with device data fields 1706 and 1708 may be used to confirm that the recorded images are current or have been recorded within a predetermined time period. For example, some windows on medical devices display the current date and time. This information may be extracted by image processor 1604 and identified using device data fields 1706 and 1708. Image processor 1604 compares the extracted date/time to date/time rules or limits associated with device data fields 1706-1708 to determine whether the recorded image is current. . For example, image processor 1604 may determine if the date does not match or the time is within a predetermined threshold (eg, 5 minutes, 15 minutes, 60 minutes, 3 hours, etc.) of the current time on personal mobile communication device 200a. If not, it may be determined that another image is required to be recorded.

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

As discussed above in connection with FIG. 17, data processor 1602 of FIG. 16 uses known locations of text and text indicators within the image to determine extracted text that corresponds to relevant medical information. relationships can be used. 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 instructions are determined from a previous image of the identifier 1012, received from the patient via the camera user interface 1606, and/or defined through selection of data fields in the user interface for the application 1002 in which medical information is to be populated. can be done. In other examples, data processor 1602 compares data templates in database 1608 to images with extracted text to find matches. In these other examples, the data processor 1602 uses text indicators and the location of the text between the image and the data template to determine the match.

After identifying the relevant medical information, the example data processor 1602 is configured to write or otherwise populate one or more data fields of the user interface of the application 1002 with the relevant medical information. In some embodiments, data processor 1602 is configured to use data templates to automatically populate data fields in a user interface of application 1002. To automatically populate the medical information, the data processor 1602 merges the text, indicators, and/or metadata associated with the fields of the data template with the text, indicators, and/or metadata of one or more user interfaces of the application 1002. , and/or other data field information. If at least some of the text, indicators, and/or metadata match, data processor 1602 identifies some text (eg, a number) that corresponds to the matching field of the data template. The identified text is written to the corresponding matching data field of the application 1002 user interface.

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

After image 1800 is recorded, application 1002 performs an OCR operation to extract the text. Application 1002 then determines a data template 1801 that corresponds to the extracted text. In some embodiments, application 1002 matches text and/or indicator locations in the image to text and/or indicator locations in the data template to find a matching data template. In other examples, the patient may define instructions for the blood pressure monitor 104, which allows the application 1002 to find the corresponding data template 1801. In yet another example, the application 1002 may first prompt the patient to record an image of the identifier 1012a of the blood pressure monitor 104. Data from the identifier is used by application 1002 to select a data template. Regardless of how data template 1801 is identified, application 1002 applies data template 1801 to the extracted text within image 1800. This process includes application 1002 identifying groups or fields of similar text. In some instances, application 1002 may identify groups or fields of similar text based on spacing between characters and/or words.

In the illustrated example of FIG. 18, application 1002 provides fields 1802, 1804a, 1804b, 1806, 1808, and 1810 for different sets of text. The patient selects the field in which data is to be populated into the selected data field of user interface 1400. For example, to populate systolic blood pressure data field 1402, the patient selects field 1804a. The selection by the patient causes application 1002 to copy at least some of the data from field 1804a to data field 1402. Data field 1402 may include a rule specifying that only numeric integers may be accepted. Application 1002 reads text for a numeric integer (ie, "145") from selected field 1804a. Application 1002 then populates systolic blood pressure data field 1402 with the identified numerical integer. The patient may continue using image 1800 with respect to other fields 1404-1410 of user interface 1400. In each case, the patient may choose to enter data manually, wirelessly, or via 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 recorded image. Application 1002 thus allows a patient to enter information into user interface 1400 using one or more recorded images, just as if the patient were entering values manually.

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

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

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

Prior to block 1906, the patient uses application 1002, selects a data field, and selects that medical information is to be provided via photo entry. At block 1906, the personal mobile communication device 200a records an image 1907 of a medical device, consumable, patient, etc. The image may include an identifier and/or a screen of the medical device. Personal mobile communication device 200a then determines or identifies text within the recorded image (block 1908). For example, personal mobile communication device 200a may perform an OCR routine on an image. In instances where the image includes a barcode and/or QR code, personal mobile communication device 200a decodes the barcode and/or QR code. The imaged or encoded data is converted to text or American Standard Code for Information Interchange ("ASCII") characters. In some embodiments, personal mobile communication device 200a may also determine data fields for the identified text (block 1910). Data fields may be determined using data templates, for example. As described above in connection with FIGS. 17 and 18, the data template defines the location of certain text and/or operatively overlies the identified text in the recorded image. may specify certain textual indicators that are used to set up the text. In some cases, data fields and/or data templates may be selected by the patient and/or determined from the medical device identifier 1012. Alternatively, instead of using a template, procedure 1900 may instead provide an indication that recently recorded images have relevant medical information for extraction, selection, and/or transfer.

The example procedure 1900 continues in one embodiment by determining whether there are additional images to record (decision block 1912). In some examples, procedure 1900 may access a list of images that need to be recorded for a prescribed therapy or treatment. The procedure 1900 guides the patient, via the personal mobile communication device 200a, through a sequence to acquire all required images or medical information determined to be needed or missing. may provide a prompt to obtain an image containing the image. In other cases, the patient may decide which images are needed. If additional images are to be recorded, procedure 1900 returns to block 1906.

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

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

After the selected text is populated, the personal mobile communication device 200a determines whether additional relevant medical information should be populated based on the selection of additional data fields in the user interface. (Decision block 1918). In some examples, personal mobile communication device 200a operates a sequence or routine that provides prompts for the patient to select appropriate text and/or images to populate the data fields. If additional relevant medical information exists, as determined at decision block 1918, the procedure 1900 returns to blocks 1914-1916 and the patient enters the image and/or relevant medical information for data field input. stipulate. If there is no additional relevant medical information for input, as determined at decision block 1918, the example procedure 1900 ends.

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

The example application 1002 on the personal mobile communication device 200a is configured to accept images and/or text provided by a patient. In some embodiments, application 1002 is configured to allow the patient to select text or photo input. If the patient selects text entry, application 1002 displays a text box. The patient enters information into the text boxes, which is stored by application 1002. Application 1002 may then transmit the information in one or more messages to clinician server 200b. Application 1020 at clinician server 200b determines the appropriate patient medical record in database 1010 and locates the "notes" or free text field. Application 1020 stores the patient-provided text in the field. In some cases, application 1020 may also include a time/date stamp along with the entered text. This information provides the clinician with additional information from the patient, including feedback regarding treatment.

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

(5. Manual/wireless/image input embodiment of medical information via text)
In some embodiments, the personal mobile communication device 200a of FIGS. 10-12 may not be capable of installing or operating the application 1002, or the patient may decide not to install the application 1002. obtain. However, clinician server 200b still registers personal mobile communication device 200a during the registration process. Instead of receiving medical information via the application 1002, the data acquisition module 1104 of the clinician server 200b uses a routine or algorithm to prompt for medical information from the patient via the personal mobile communication device 200a or otherwise Decide what should be done to get it to. The example data acquisition module 1104 may determine that the personal mobile communication device 200a is registered, but the application 1002 is not installed, by reading the patient's registration file and/or medical record.

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

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

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

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

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

Instead of receiving messages with text, data acquisition module 1104 may also receive messages with photo attachments. Similar to the process described above in connection with FIGS. 16-19, data acquisition module 1104 processes the image, extracts text, and identifies relevant medical device data for one or more data fields of the medical record. configured to do so. Further, while the above disclosure describes the use of text messages, the data acquisition module 1104 may additionally or alternatively be used via other communication media such as email, instant or web-based messages, social media posts, etc. Medical information and/or photos may be received.

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

The example template 2100 includes predetermined fields 2102, 2104, 2106, 2108, 2110, 2112, 2114, 2116, 2118, and 2120 that correspond to Renal Failure Therapy Treatment (“RFT”). The example data acquisition processor 1104 may select the template 2100 based on the treatment prescribed for the patient. Although RFT template 2100 is illustrated, the example data acquisition module 1104 may select other templates specifically configured for pre-therapy data acquisition, post-therapy data acquisition, etc. For example, a pre-therapy acquisition template may include data fields regarding blood pressure, pulse, and weight.

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

In some embodiments, data acquisition module 1104 is configured to select template 2100 based on prompts from the patient. For example, the patient may send a message to data acquisition module 1104 that includes the text "Manual Exchange." In response, data acquisition module 1104 identifies and selects a template 2100 for manual exchange. In another example, the patient may send a message to the data acquisition module 1104 via the personal mobile communication device 200a that includes the text "Before treatment" or "Start treatment." In response, data acquisition module 1104 identifies and selects a template for acquiring the required medical information before treatment can begin.

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

The example 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 an image recorded by personal mobile communication device 200a of patient's identifier 1012 (or patient-worn identifier 1012). Blood pressure field 2108 may be populated from an image recorded by personal mobile communication device 200a of the screen of blood pressure monitor 104, while weight field 2106 may be populated from an image recorded by personal mobile communication device 200a of the screen of scale 106. Data can be input from. Date field 2110, removed UF field 2112, and fluid fill field 2114 may be populated from an image recorded by personal mobile communication device 200a of the screen (showing the treatment status window) of home therapy machine 90. Similarly, the glucose level field 2116 may be populated from an image recorded by the personal mobile communications device 200a of the home therapy machine 90's screen (showing the settings window), and the prescription identifier field 2118 may be populated from an image recorded by the personal mobile communication device 200a of the home therapy machine 90's screen (showing the settings window). It may be populated from an image recorded by the personal mobile communication device 200a of the screen (showing the prescription window). Finally, the cassette identifier field 2120 may be populated from an image recorded by the personal mobile communication device 200a of the identifier 1008 of the disposable cassette consumable item 1006. As discussed above, instead of receiving images containing medical information, data acquisition module 1104 may receive one or more messages with text regarding fields 2102-2120.

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

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

At least some of the routine modules 2152-2164 may be associated with or otherwise related to a data template (eg, data template 1700 of FIG. 17). Data acquisition module 1104 is configured to access data templates for corresponding routine modules 2152-2164 when a patient provides images and/or text in a message. For example, while executing the blood pressure routine module 2156, the data acquisition module 1104 transmits a message prompting the personal mobile communication device 200a for a "systolic blood pressure measurement." The patient responds with a text message that includes an image of the blood pressure monitor 104 screen or dial. Data acquisition module 1104 is configured to access data templates that correspond to or are referenced by blood pressure measurement routine module 1156. Data acquisition module 1104 then applies the data template to extract text from the image and populate blood pressure data field 2108 of template 2100 using the procedures described above in connection with FIGS. 16-19. Identify relevant systolic blood pressure medical information for.

The example routine 2150 may be configured to be initiated upon request from the patient and based on one or more messages received by the data acquisition module 1104. For example, data acquisition module 1104 may receive a message with text that includes "start," "start," and/or "pre-therapy." Receipt of the message causes the data acquisition module 1104 to determine and initiate a routine 2150 for populating the data fields 2102-2120 of the template 2100. In other examples, data acquisition module 1104 transmits a first message defined by routine 2150 to the patient at a predetermined time for treatment. After data acquisition module 1104 receives a response message with appropriate medical information from personal mobile communication device 200a, data acquisition module 1104 continuously transmits messages defined by routine 2150. In this manner, data acquisition module 1104 controls the acquisition of medical information from patients according to a predetermined sequence. Data acquisition module 1104 is configured as defined by routine 2150 until an appropriate response message is received from personal mobile communication device 200a (and medical information is populated into designated data fields 2102-2120 of template 2100). The next message in the sequence may not be transmitted.

In the illustrated example, patient band module 2152 may include metadata or pre-formatted messages instructing the patient to record an image of the patient's wristband. Patient band module 2152 may also include character validation checks to ensure that the received medical information complies with text requirements for patient names and/or patient identifiers. For example, patient band module 2152 may exclude or discard medical information regarding a patient's name that includes numbers.

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

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

The cassette module 2164 includes metadata or pre-formatted messages instructing the clinician or patient to record an image of the identifier 1008, the disposable cassette consumable item 1006, and/or the indicia on the packaging or the cassette consumable itself. may include. 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.

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

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

To populate the data fields, the data acquisition module 1104, in some embodiments, reads the names of the data fields 2102-2120 (and any corresponding metadata) and sends messages prompting recording of certain images. can be created and sent to the patient. In one example, weight data field 2106 includes metadata that identifies the scale as the associated medical device. Data acquisition module 1104 determines that data field 2106 is blank and sends a message instructing the patient at personal mobile communication device 200a to read the corresponding metadata and record an image of the scale screen. To construct. In the illustrated embodiment, the data acquisition module 1104 continuously progresses through the template 2100 (or the patient's medical record), searching for unfilled data fields, and messages displayed by the personal mobile communication device 200a, as appropriate. Medical information may be requested from the patient via the . Alternatively, data acquisition module 1104 may proceed through template 2100 according to a predetermined order or sequence. For example, the data acquisition module 1104 may first retrieve data fields associated with a patient's wristband, followed by data fields related to a scale medical device, data fields related to a blood pressure medical device, and data fields related to a renal failure therapy medical device. Fields can be searched.

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

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

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

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

In addition to sending messages, template processor 2204 may be configured to select data templates. Data templates are stored in data template database 2208 in the illustrated embodiment. Template processor 2204 selects a data template based on the type or model of the medical device indicated in the medical information corresponding to identifier 1012. In some cases, the patient may specify the model and/or type of medical device type to template processor 2204 via a message. Further, as discussed above, template processor 2204 receives images from personal mobile communication device 200a, extracts text from the images, and identifies relevant medical information from the images, as described above. An appropriate data template may be selected from database 2208 for the purpose.

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

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

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

The example procedure 2300 begins in FIG. 23 when the clinician server 200b of FIGS. 10-12 and 22 receives a message 2301 from the personal mobile communication device 200a (block 2302). Message 2301 indicates a request to initiate a treatment to be performed on a patient or to send medical information. Clinician server 200b then determines a patient medical template (e.g., patient medical template 2100 of FIG. 21) based on the treatment type specified in message 2301 or the prescribed treatment specified in the patient's medical record. (Block 2304). In instances where clinician server 200b only provides completion of one type of template (eg, a template for renal failure therapy), message 2301 may indicate a request to begin populating blank templates. In response to message 2301, clinician server 200b creates a copy of the patient care template for data entry.

After providing a patient medical template for data population, clinician server 200b identifies at least one medical device for which medical information is needed (either using routines associated with the template or by reading the template itself). is determined and, accordingly, a first camera message 2305 is transmitted to the personal mobile communication device 200a (block 2306). First camera message 2305 includes, for example, instructions indicating that an image of medical device identifier 1012 is to be recorded. Some time later, clinician server 200b receives a message 2307 that includes medical information indicating the type of medical device (eg, medical information from identifier 1012a) (block 2308). Clinician server 200b then determines a device data template (e.g., device data template 1700 of FIG. 17) based on information contained within message 2307 or specified in the patient's medical record (block 2310). ). For example, after determining that message 2307 identifies blood pressure monitor 104 (type and/or model), clinician server 200b determines or finds a device data template for the blood pressure monitor. Clinician server 200b loads a device data template to identify relevant medical device data from the received image of the blood pressure monitor 104 screen (block 2312).

The example procedure 2300 continues in FIG. 24 with the clinician server 200b transmitting a second camera message 2313 to the personal mobile communication device 200a (block 2314). Second camera message 2313 may be determined based on the type of medical device defined by message 2307. Further, the second camera message 2313 may include information to display a certain window (or related medical information) on the medical device to record the image. Some time later, clinician server 200b receives a message 2315 that includes text or an image thereof from a window of the medical device (block 2316). The example clinician server 200b uses the identified data template to extract relevant medical information from the image and determines or otherwise identifies data fields of the patient medical template that correspond to the relevant medical information. (Block 2318). If message 2315 includes text, clinician server 200b determines or otherwise identifies the data field of the patient medical template that corresponds to the relevant medical information. Clinician server 200b then populates the template's determined and/or identified data fields with relevant received medical information (block 2320).

After populating the relevant data fields, the example clinician server 200b determines whether additional relevant medical information is needed from the medical device associated with the received relevant medical information. (Decision block 2322). For example, clinician server 200b may determine that the current medical device may include additional windows or motion displays where relevant medical information is still needed. If additional medical information is needed, the example clinician server 200b returns to block 2314 and transmits a camera message 2313 for another window for which related medical information is needed. However, if no additional medical information is needed with respect to the current medical device, clinician server 200b determines whether medical information is needed from other medical devices (or consumable items 1006). (Decision block 2324). If additional medical information is required, the clinician server 200b returns to block 2306 and transmits a camera message 2305 identifying another medical device for imaging or receiving related medical information. do. If no additional medical information is needed for completion of the patient medical template 2100, the example clinician server 200b stores the completed patient medical template 2100 as the patient's medical record in the clinician database 1010; Procedure 2300 ends.

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

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

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

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

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

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

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

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

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

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

(C. Data access module embodiment)
Turning again to FIG. 11, the example data access module 1106 is configured to provide patients and clinicians with access to medical information stored within medical records in the clinician database 1010. As described above in connection with data acquisition module 1104, there are different possible configurations of personal mobile communication device 200a, which may or may not have application 1002 installed. Data access module 1106 is configured to provide access or otherwise display data based on configuration. To determine the configuration being used by a particular patient, the example data access module 1106 accesses the registration table or patient's medical record and identifies the registered personal mobile communication device 200a and/or the application 1002 installed. configured to identify whether the

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

The example data access module 1106 may determine whether medical and/or treatment information within the patient's medical record should be converted to a different format prior to transmission. For example, medical and/or treatment information may be stored within the medical record in HL7 format. However, this format is not suitable for text messages and/or applications. The example data access module 1106 determines the capabilities of the personal mobile communication device 200a over which data is to be transmitted. Data access module 1106 determines capabilities based on registration information indicating whether application 1002 is installed and/or whether personal mobile communication device 200a is a feature-rich device. To view medical information on application 1002, data access module 1106 uses one or more APIs to retrieve medical and/or treatment information from HL7 format, such as Hypertext Markup Language (“HTML”). ) format, JavaScript Object Notation (“JSON”) format, or XML format (eg, an application format). If data access module 1106 determines that application 1002 is not installed, data access module 1106 converts the information from HL7 format to text message or SMS message format, e.g., via one or more APIs. do. The example data access module 1106 thus allows patient medical record information to be viewed by the patient regardless of the capabilities of his or her personal mobile communication device 200a.

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

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

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

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

The example user interface 2700 of FIG. 27 illustrates the average drain time for each UF replacement. Evacuation time is provided in graph 2702. Between user interfaces 2600 and 2700, the patient can measure how the treatment is progressing over time. Any deviations in treatment should be readily apparent and helpful in persuading the patient to comply with the prescribed therapy.

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

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

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

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

In one example, data access module 1106 may receive a text message that includes the text "Send 7 days of UF data." In response, data access module 1106 identifies the patient record that corresponds to the telephone number of personal mobile communication device 200a from which the text message was received. Data access module 1106 then uses a lookup table or keyword search to identify fields within the patient's medical record that include matching sets of characters or text related to UF data (e.g., "7 days of UF"). can be identified. Data access module 1106 copies the matching text and creates a return message with the UF values for the previous seven days, which is transmitted to personal mobile communication device 200a. Additionally or alternatively, data access module 1106 creates and renders a seven-day graph similar to graph 2602 of FIG. 26. Data access module 1106 creates an image of the graph, which is transmitted to personal mobile communication device 200a as an image within a text message. The image is... jpeg,. gif,. It can be stored as a file such as png. A patient at personal mobile communication device 200a may view the graph via text message. In this manner, the example data access module 1106 is configured to provide patient access to medical and treatment information regardless of the capabilities and/or operating system of the own personal mobile communication device 200a. In addition, the data access module 1106 determines how the data is to be transmitted based on registration information provided by the patient and/or an indication of whether the application 1002 is installed on the patient's personal mobile communication device 200a. Determine.

(4. Alarm/Alert Embodiment)
In addition to providing a display of medical and/or treatment information, the example data access module 1106 of FIG. 11 may determine alarms and/or alerts for patients and/or clinicians, and/or configured to occur. Data access module 1106 may send alarms and/or alerts to patient's personal mobile communication device 200a or clinician device 152. In some embodiments, data access module 1106 may include a rules table that defines the devices to which certain alarms/alerts should be transmitted. A clinician may use clinician device 152 to subscribe to certain alarms/alerts and/or patients.

Data access module 1106 is configured to provide alarms/alerts based on how personal mobile 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 application 1002. In some instances, application 1002 is configured to display a notification indicating an alarm/alert. If application 1002 is not installed, data access module 1106 determines that the alarm and/or alert should be transmitted to personal mobile communication device 200a via SMS or other text message.

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

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

In some instances, the patient is prescribed a manual exchange. Therefore, there is a need for the patient to provide treatment information indicating manual replacement. 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 (eg, within two days after a scheduled treatment). Additionally, if the manual exchange is not completed properly (eg, short fill or dwell time), the data access module 1106 sends an alert and/or alarm regarding the insufficient exchange. To determine insufficient replacement, data access module 1106 may compare fill, dwell, and/or drain times to pre-established acceptable ranges and/or thresholds. In some cases, data access module 1106 may request that the patient perform a complete exchange.

In certain examples, alarms and/or alerts may be generated to indicate that the patient should select a different treatment program from multiple prescribed treatment programs or make adjustments to the treatment program. . In this example, an alarm or alert rule may specify that the data access module 1106 should calculate the accumulated fluid value and compare it to some threshold while comparing the patient's blood pressure or weight to the respective change threshold. . Accumulated fluid values may be determined from individual fluid fill and drain volumes, which indicate the fluid remaining within the patient's peritoneal cavity. If the blood pressure or weight and accumulated fluid values (or trends) are outside of acceptable ranges, the data access module 1106 generates an alarm. The alarm indicates that the patient is accumulating fluid and a treatment program with a longer drain duration (or a shorter filling duration) should be selected (or a treatment program with a longer drain duration or a shorter (should be adjusted to provide a filling duration). Data access module 1106 transmits the alarm for display on personal mobile communication device 200a. The patient may respond via application 1002 or text message and cause clinician server 200b to make appropriate changes to the patient's prescription or therapy program.

In some embodiments, alarms and/or alerts may define conditions under which additional information should be prompted from the patient. In these embodiments, data access module 1106 uses treatment information from home therapy machine 90 as the basis for determining whether the patient should provide medical information via personal mobile communication device 200a. In certain examples, the data acquisition module 1106 may access alarm and/or alert rules that define conditions under which a prompt or text message prompting for additional weight or blood pressure measurements is sent to the patient's personal mobile communication device 200a. . For example, an alarm or alert may specify that if a blood pressure value (or trend) exceeds a predetermined threshold, a prompt for a new blood pressure measurement is required. In other examples, an alarm or alert may specify that a prompt for a new blood pressure measurement is required if the accumulated fluid value or removed UF value (or trend) is outside of an acceptable range. In response, data access module 1106 transmits a text message or notification via application 1002 for the patient to perform and record a blood pressure measurement. In some instances, application 1002 may open a user interface (eg, user interface 3000 of FIG. 30) that prompts the patient to enter blood pressure information. If the additional data received from personal mobile communication device 200a is not within an acceptable range, data access module 1106 escalates the alert to an alarm that is transmitted to clinician device 152 and/or personal mobile communication device 200a. It can be done. Accordingly, the data access module 1106 operates rules to determine borderline patient conditions that require additional information from the patient before determining whether further attention or action is requested from the clinician or the patient. configured.

In further embodiments, the data access module 1106 rules may instruct the patient to inspect the home therapy machine 90 and/or make changes thereto. In one example, the rule specifies that if treatment information is not received from the home therapy machine 90 within a defined period of time (e.g., two days), the data access module 1106 should transmit an alert to the patient. It is possible. In this situation, the patient may have provided medical information indicating that the treatment has been administered, which the data access module 1106 uses to ensure that no alerts regarding compliance with the treatment are necessary. decide. Alternatively, the data access module 1106 determines that an alert should be transmitted to the patient to check the network connectivity of the home therapy machine 90 so that the therapy information stored on the machine 90 can be retrieved. Determine. The patient may respond to the alert using personal mobile communication device 200a to indicate that the connection has been checked. After a response from the patient is received, data acquisition module 1104 may send a ping message to home therapy machine 90 regarding the missing treatment information. If the connection still cannot be made, the data access module 1106 issues an alert with more specific instructions to activate the home therapy machine 90 and/or to overcome the network connectivity problem. may be sent to the patient, clinician, and/or network administrator.

In another example, data access module 1106 may include one or more rules that specify that an alert should be generated in response to treatment information being out of range. For example, a large difference between fluid fill volume and drain volume may indicate a leak in the dialysis tubing or connection to the patient. In response, data access module 1106 transmits an alert to the patient prompting the patient to verify the fluid connection. The patient may provide a response indicating whether a leak has been detected. In response, data access module 1106 determines whether the leak has been corrected in a subsequent treatment cycle (or main sequence) or whether the tubing should be replaced. Data access module 1106 may determine similar consumable issues regarding cassettes, 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 to verify the concentration of the dialysis fluid and/or concentrate that the patient is connected to the home therapy machine 90. .

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

The prescription and associated program are stored in an electronic prescription within clinician database 1010. In some embodiments, the prescription may be stored in the patient's medical record. Home therapy machine 90 is programmed with one or more prescriptions. Programming may be performed locally via the clinician or patient, or remotely from the clinician server 200b. For example, clinician server 200b (eg, therapy control module 1110) may send a copy of the prescription from clinician database 1010 to home therapy machine 90 after registration.

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

After the patient selects a different program via user interface 3100, application 1002 sends a message to therapy control module 1110 indicating the selection. In response, treatment control module 1110 updates the patient's medical record to reflect the changed program, including the time/date of the change. Additionally, therapy control module 1110 transmits messages to home therapy machine 90 providing instructions to modify the selected program. In some cases, the message may include treatment parameters for the newly selected program. Home therapy machine 90 accordingly implements the next therapy based on the newly selected program. In some instances, home therapy machine 90 may display a prompt for the patient to confirm a new program before operating according to the program.

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

In certain embodiments, therapy control module 1110 may send a notification to clinician device 152 indicating that the patient desires to change the program. Therapy control module 1110 may not communicate changes to home therapy machine 90 until confirmation is received from clinician device 152. In some embodiments, a clinician may use his or her clinician device 152 to modify programs and/or prescriptions via the therapy control module 1110. In these embodiments, therapy control module 1110 may send a message for display in application 1002 of personal mobile communication device 200a indicating changes in the program and/or that the clinician has made the changes.

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

Additionally or alternatively, therapy control module 1110 is configured to allow therapy changes via text messages. In one example, the patient may send a message from personal mobile communication device 200a that includes the text "Change treatment." In response, therapy control module 1110 is configured to send a return message with different therapy program options and a corresponding code or indicator next to each option. The patient may enter an indicator or code within the response message to select the desired program. In another example, the patient may send a message with the text consisting of, for example, "Long Term Program" to cause the therapy control module 1110 to change the program to a long term program.

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

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

As also described herein, encouragement includes text, audio, video, or multimedia presentations designed to improve the patient's mood or help the patient adhere to the program. Incentives may also include rewards or badges. In some embodiments, the education module 1108 may be configured to provide incentives based on the detected condition. In some cases, incentives may be provided in conjunction with alerts generated by data access module 1106. In some examples of incentives, different status levels may be provided to patients based on rate of compliance (eg, "Dialysis Superstar" for near perfect compliance).

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

In some examples, data access module 1106 determines that the patient is not compliant with treatment. In addition to data access module 1106 sending alerts, education module 1108 may recommend or provide links to videos regarding the importance of compliance. FIG. 32 shows an example user interface 3200 of application 1002 that displays compliance-related educational videos provided by education module 1108. The example user interface 3200 also provides a list of recommended educational materials based on the patient's detected condition. For example, after detecting from a medical record or receiving as medical information that a patient has high blood pressure, the education module 1108 is configured to recommend educational content about lowering blood pressure. Further, after detecting that the patient has not changed the program of the prescription, the education module 1108 determines that educational content that explains the program options should be recommended.

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

The example education module 1108 may store any educational content or incentive instructions displayed by the personal mobile communication device 200a in the patient's medical record. Such information can be useful to clinicians for determining how patients are participating in treatment. The stored information may also provide an indication of the patient's awareness of the treatment.

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

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

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

In some embodiments, the auxiliary module 1112 may determine that a communication session should be opened or recommend that a communication session be opened. Auxiliary module 1112 may provide recommendations in conjunction with data access module 1106 generating alarms and/or alerts. After detecting a condition related to the alert and/or alarm, the auxiliary module identifies clinician devices 152 that are available to participate in the session and then uses the personal mobile communication to address the alert and/or alarm. A call may be initiated to device 200a. In some examples, the auxiliary module 1112 is configured to create a communication session after detecting that the patient's blood pressure, weight, accumulated fluid, etc. exceeds a predetermined threshold or changes significantly within a predetermined period of time. You can try.

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

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

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

Claims (13)

A machine-accessible device storing instructions, the instructions being configured, when executed, to cause the machine to populate a patient medical record of a clinical system, the instructions comprising: Inputting data is
Operating the camera and recording images;
operating a display interface;
operating a connection interface configured to connect to a clinician database, the clinician database configured to store patient medical records;
operating the processor and obtaining medical information;
Obtaining the medical information includes:
displaying, via the display interface, a user interface with fields to be populated with medical information;
After selection of a data field in the user interface, a first option for inputting medical information from an image and a second option for inputting medical information via text input are displayed graphically via the display interface. to provide the
If the first option is selected,
receiving a recorded image from the camera, the recorded image comprising a medical device or a screen of a medical device;
extracting text from the image;
determining a data template for the extracted text on the image;
processing the extracted text using the data template and classifying the extracted text into fields;
enabling selection of at least one of the fields via the display interface;
writing the selected text from the image as the medical information into the data field of the user interface;
if the second option is selected, enabling text entry of the data field as the medical information via the display interface;
after a transmission command is received, transmitting the medical information written in the data field as structured data to at least one corresponding data field of a patient medical record stored in the clinician database; Therefore, it is done,
The machine-accessible device , wherein the data template is configured to define a context for the extracted text in relation to text position within the image . further comprising instructions stored on the machine-accessible device, wherein the instructions, when executed, are configured to cause the machine to operate the processor, the processor (i) providing medical care via the user interface; selection of a device type; (ii) information scanned from an identifier located on the medical device; (iii) an indicator within the extracted text; or (iv) relative positioning of the extracted text. The machine-accessible device of claim 1 , determining the data template based on at least one of the following: The identifier located on the medical device may be a quick response (“QR”) code, bar code, serial number, or hardware located on the housing of the medical device or on the screen of the medical device. 3. The machine-accessible device of claim 2 , comprising at least one of the numbers. 2. The machine-accessible device of claim 1, wherein the medical device includes at least a renal failure therapy machine, an infusion pump, an oxygen sensor, a respiration monitor, a glucose meter, a blood pressure monitor, an ECG monitor, a weight scale, and a heart rate monitor. The data field of the user interface stores at least one of blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual replacement data, subjective data, or consumable data regarding a consumable item. The machine-accessible device of claim 1, configured to receive. 5. The consumable item includes at least one of a filter, a blood line set, a dialysate concentrate container, a blood anticoagulant container, a drug container, a disposable cassette, a sorbent cartridge, and a water purification container. Machine-accessible devices as described in . The machine-accessible device of claim 1, wherein the machine is a personal mobile communications device. A method of populating a patient medical record in a clinical database using recorded images, the method comprising:
transmitting a first message to a personal device, the first message prompting the patient to record a first image of the medical device using a camera of the personal device; ,
receiving the first image from the personal device;
determining, via a processor, first medical information from the first image indicating a type or model of the medical device;
determining, via the processor, a data template and a second message associated with the determined type or model of the medical device;
transmitting, via the processor, the second message to the personal device, the second message configured to record a second image of a screen of the medical device using the camera; prompting said patient to;
receiving the second image from the personal device via the processor;
extracting text from the second image via the processor;
processing the extracted text using the data template via the processor and classifying the extracted text into fields;
determining, via the processor, a correspondence between at least one of the fields and a record field within the patient medical record;
writing, via the processor, at least a portion of the text from the at least one of the fields to the record field in the patient medical record. determining a treatment time from the patient medical record via the processor;
9. The method of claim 8 , further comprising: transmitting the first message via the processor prior to the treatment time. receiving, at the processor, a treatment message from the personal device indicating that the patient should begin treatment;
9. The method of claim 8 , further comprising: transmitting the first message via the processor before the therapy is initiated. The first image is received at the processor via a first Multimedia Messaging Service (“MMS”) message, and the second image is received at the processor via a second MMS message. , the method according to claim 8 . further comprising converting, via the processor, the at least a portion of the text from the at least one of the fields to a Health Level 7 (“HL7”) format prior to writing to the patient medical record. , the method according to claim 8 . comparing, via the processor, the at least a portion of the text from at least one of the fields to a predetermined range;
via the processor: if the at least a portion of the text from at least one of the fields is within the predetermined range; 9. The method of claim 8 , further comprising: writing the at least a portion.

Images