Method, apparatus, and system for remotely viewing a medical device screen

Abstract

Disclosed are medical device remote screen viewing methods, apparatus, and systems configured to provide a graphical representation of the screen currently being displayed by the medical device to provide sufficient context as if the clinician were physically located at the patient's bedside. In some embodiments, the medical device transmits medical data and an identifier of the displayed screen to be entered into a corresponding user interface of a software application on the clinician device. In other embodiments, the medical device transmits an image of the displayed screen that is displayed by the software application on the clinician device.

Description

[Background technology]

[0001] A person's kidney function can fail due to various causes. Renal failure leads to several physiological abnormalities. For example, a person with renal failure is unable to maintain fluid and mineral balance and is unable to excrete daily metabolic loads. Furthermore, toxic substances that are end products of metabolism, such as urea, creatinine, and uric acid, can accumulate in the patient's blood and tissues.

[0002] Declining kidney function, particularly kidney failure, is treated with dialysis, which removes waste products, toxins, and excess fluid from a patient's body that normal kidneys would otherwise be able to remove. Dialysis, which replaces kidney function, is a life-saving treatment and is therefore very important to many people.

[0003] Hemodialysis (HD), one treatment for kidney failure, typically uses diffusion to remove waste products from a patient's blood. Diffusion occurs within a semipermeable dialyzer, where a diffusion gradient exists between the blood and an electrolyte solution (dialysate or dialysis fluid). Diffusion occurs outside the patient's body, using an extracorporeal circuit to remove unpurified blood and return purified blood to the patient.

[0004] Hemofiltration (HF) is an alternative renal replacement therapy that convectively transports toxins from the patient's blood. HF is achieved by adding replacement or substitution fluid to the extracorporeal circuit during the procedure. The replacement fluid, as well as fluid accumulated by the patient between treatments, is ultrafiltered during the HF procedure. This provides a convective transport mechanism that is particularly effective at removing medium- and large-molecule toxin molecules.

[0005] Hemodiafiltration (HDF) is a treatment modality that combines convective and diffusive clearance. In HDF, diffusive clearance is achieved by flowing dialysis fluid through a dialyzer, similar to standard hemodialysis. In addition, convective clearance is achieved by delivering replacement fluid directly into the extracorporeal circuit.

[0006] Another type of kidney failure treatment is peritoneal dialysis (PD), which involves infusing a dialysis solution (also called dialysis fluid) into a patient's peritoneal cavity via a catheter. The dialysis fluid is in contact with the peritoneal membrane within the patient's peritoneal cavity. Waste, toxins, and excess water move from the patient's bloodstream through the capillaries in the peritoneal membrane and into the dialysis fluid by diffusion and osmosis, creating an osmotic gradient across the membrane. An osmotic agent in the PD dialysis fluid provides the osmotic gradient. The used or spent dialysis fluid is pumped out of the patient, removing the waste, toxins, and excess water from the patient. This cycle is repeated multiple times.

[0007] There are various types of peritoneal dialysis therapy, including continuous ambulatory peritoneal dialysis (CAPD), automated peritoneal dialysis (APD), tidal flow dialysis, and continuous flow peritoneal dialysis (CFPD). CAPD is a manual dialysis procedure. In this procedure, the patient manually connects an implanted catheter to a drain to allow spent or used dialysis fluid to drain from the peritoneal cavity. The patient then switches the fluid connection so that the patient's catheter communicates with a bag of fresh dialysate and infuses fresh dialysate into the patient through the catheter. The patient disconnects the catheter from the fresh dialysate bag, allowing the dialysate to dwell in the peritoneal chamber, where waste, toxins, and excess water are transported. After a rest period, the patient repeats the manual dialysis procedure, for example, four times a day. Manual peritoneal dialysis requires significant time and effort from the patient, leaving ample room for improvement. There are various types of peritoneal dialysis therapy, including continuous ambulatory peritoneal dialysis (CAPD), automated peritoneal dialysis (APD), tidal flow dialysis, and continuous flow peritoneal dialysis (CFPD). CAPD is a manual dialysis treatment. The patient manually connects an implanted catheter to a drain to drain used or spent dialysis fluid from the peritoneal cavity. The patient then switches the fluid connection, connecting the patient's catheter to a bag of fresh dialysis fluid, and injects fresh dialysis fluid through the catheter into the patient. The patient removes the catheter from the bag of fresh dialysis fluid, allowing the dialysis fluid to dwell in the peritoneal cavity, where it drains waste, toxins, and excess water. After the dwell period, the patient repeats the manual dialysis procedure, e.g., four times a day. Manual peritoneal dialysis requires significant patient time and effort, leaving significant room for improvement.

[0008] Automated peritoneal dialysis (APD) is similar to CAPD in that the dialysis treatment includes drain, fill, and dwell cycles. However, APD machines perform these cycles automatically, typically while the patient sleeps. APD machines eliminate the need for patients to manually perform treatment cycles and carry supplies during the day. APD machines are fluidly connected to an implanted catheter, a source or bag of fresh dialysis fluid, and a fluid drain. The APD machine pumps fresh dialysis fluid from the dialysis fluid source through the catheter and into the patient's peritoneal cavity. APD machines allow the dialysis fluid to dwell in a chamber, allowing for the transfer of waste, toxins, and excess water. The source may contain multiple liters of dialysis fluid, including multiple solution bags.

[0009] APD machines pump used or spent dialysate from the patient's peritoneal cavity through a catheter and into a drain. Similar to the manual process, multiple drain, fill, and dwell cycles are repeated during dialysis. At the end of an APD treatment, a "final fill" may occur. The final fill fluid may be left in the patient's peritoneal cavity until the start of the next treatment, or it may be manually emptied at any time during the day.

[0010] In both of these approaches, automated dialysis machines are installed in medical centers or patients' homes. During treatment, clinicians may need to check treatment progress, treatment settings, or alerts generated by the automated dialysis machine. For treatments performed in patients' homes, visiting the automated machine is extremely difficult. Instead, clinicians must call the patient to evaluate alert or setting issues. Clinicians often must rely on descriptions provided by the patient, which may be inaccurate or lack sufficient context. Alternatively, clinicians can use devices to access the patient's electronic medical record (EMR), which contains data logs of treatment data and events generated by the automated dialysis machine. However, because the data is in a time-stamped log format consisting of strings and numbers, it can be difficult for clinicians to quickly diagnose problems. Furthermore, there is concern that the data in the logs may not represent the data displayed on the automated dialysis machine screen, further complicating the issue. Even when automated dialysis machines are installed in medical facilities, it may be inefficient or impossible for clinicians to visit patients and the automated dialysis machine to help identify and resolve treatment or setting issues. Furthermore, even if clinicians are able to visit an automated dialysis machine, they only have real-time information available on a screen; reviewing dialysis settings and treatment history requires sifting through data logs, a tedious and time-consuming process.

[0011] Therefore, there is a need for a dialysis system that provides a clinician with additional context regarding the dialysis treatment without requiring the clinician to be present at the automated dialysis machine. Summary of the Invention

[0012] Disclosed herein are exemplary systems, methods, and devices for providing a remote view of an automated dialysis machine's user interface. The systems, methods, and devices are configured to provide a graphical representation of the screen currently being displayed by the automated dialysis machine to provide sufficient context as if the clinician were physically located at the patient's bedside. As described herein, there are several different ways in which the systems, methods, and devices can provide a remote view of the automated dialysis machine's screen.

[0013] In some embodiments, the systems, methods, and apparatus transmit only medical data, screen identifiers, and timestamps from the automated dialysis machine. In these embodiments, a software application running on a clinician device stores blank user interface templates of possible screens that can be displayed by the automated dialysis machine. The software application receives the medical data, screen identifiers, and timestamps and uses the screen identifiers to select a corresponding blank user interface. The software application then uses labels provided with the medical data to populate corresponding data fields in the user interface to generate a populated user interface. Such a configuration allows the software application to display the same screens displayed by the automated dialysis machine without having to transmit screen images, which consumes a moderate amount of bandwidth and processing.

[0014] The use of the timestamps allows the software application to create a screen progression video to show how the automated dialysis machine performed over time as new medical data was generated, thereby providing additional context to help clinicians diagnose potential configuration or treatment problems. The video feature allows clinicians to see what was happening with the automated dialysis machine before a problem occurred, which can be useful in determining the root cause of the problem. In addition to storing the screen progression video within the software application, the systems, methods, and apparatuses disclosed herein can additionally or alternatively store the screen progression video on a memory device of the automated dialysis machine, in a database managed by a medical server, and / or in a cloud-based database.

[0015] In some examples, bandwidth is further reduced by the automated dialysis machine transmitting the medical data only when at least some of the medical data has changed. The automated dialysis machine may transmit only the medical data on a currently displayed screen that has changed or transmitted all of the medical data shown on the screen when at least some of the data has changed. Additionally, some of the user interfaces (and screens) may include scales, graphs, gauges, or other graphical elements that change based on the value of the associated medical data. The user interface includes coding that appropriately changes the graphical elements based on the associated value of the medical device data.

[0016] In alternative embodiments, the systems, methods, and devices are configured to generate images, such as JPEG images, PNG images, etc., of the automated dialysis machine screen. The systems, methods, and devices are configured to provide the images to the software application. Each image may be time-stamped, allowing the images to be sequenced to create a screen progression video. In these alternative embodiments, a virtual network computing (VNC) server receives the images and stores them in shared memory or a cloud-based database, which may be protected by the automated dialysis machine's address and password. The software application allows a user to provide the automated dialysis machine's address and password to access the images. While these alternative embodiments may use more network bandwidth to transmit images of the automated dialysis machine screen, they require less processing associated with user interface selection and input of data for display on the software application.

[0017] In some embodiments, the systems, methods, and devices are configured to provide confirmation that the medical data represented as shown on the screen of the automated dialysis machine is accurate. In these embodiments, the systems, methods, and devices are configured to include a camera aimed at the screen of the medical device. Images captured by the camera are transmitted to the server and / or the software application for display adjacent to the input user interface and / or the screen image. A clinician can visually compare the camera image with the input user interface and / or the screen image to ensure the medical data is accurate and up-to-date and to ensure the displayed screen is accurate. In some examples, the software application and / or the server can perform optical character recognition and / or pixel analysis between the camera image and the input user interface and / or the screen image to provide automatic confirmation. If there is a discrepancy, the software application and / or the server can generate an alert indicating that the input user interface and / or the screen image may be inaccurate.

[0018] In light of the disclosure herein, and in a first aspect of the present disclosure, which may be combined with any other aspects enumerated herein without limiting the disclosure in any way, a system for remotely viewing medical data displayed on a screen of a medical device includes a medical device for performing a medical procedure for a patient. The medical device includes a plurality of different screens that can be displayed on a display device, each screen being assigned an identifier and configured to display a subset of medical data related to the medical procedure. The medical device is configured to transmit an identifier of a screen displayed by the display device of the medical device and the medical data displayed on the screen. The system also includes a user device including a processor and a memory, the memory storing instructions, when executed by the processor, that cause the processor to operate a software application including a plurality of blank user interfaces corresponding to the plurality of different screens of the medical device. Each user interface includes at least one data field corresponding to the subset of medical data associated with the associated screen. The system further includes a server communicatively connected to the medical device and the user device via a network. The server is configured to receive the identifier of the screen displayed by the medical device and the medical data displayed on the screen. After receiving a request message from the software application of the user device, the server is configured to send the identifier of the screen displayed by the medical device and the medical data shown on the screen, causing the software application to select an uninputted user interface corresponding to the identifier of the screen and input the received medical data into at least one data field of the selected user interface.

[0019] In a second aspect of the present disclosure, which may be combined with any other aspect enumerated herein, the medical device is further configured to transmit a timestamp along with the identifier of the screen and the medical data shown on the screen, and the server is further configured to store the timestamp in a medical record associated with the patient in association with the identifier of the screen displayed by the medical device and the medical data shown on the screen.

[0020] In a third aspect of the present disclosure that may be combined with any other aspects enumerated herein, the server is further configured to receive, after the first timestamp, a second timestamp and at least one of (i) a second identifier of a second screen displayed by the display device of the medical device and second medical data shown on the second screen, or (ii) the identifier of the screen displayed by the display device of the medical device and updated medical data shown on the screen, and the server is further configured to store the at least one of (i) or (ii) in the medical record associated with the patient.

[0021] In a fourth aspect of the present disclosure that can be combined with any other aspect listed herein, the software application is further configured, for (i), to select a second uninputted user interface corresponding to the second identifier of the screen, input the received second medical data into at least one data field of the selected second user interface, and create a screen progression video using the user interface associated with the timestamp and the second user interface associated with the second timestamp.

[0022] In a fifth aspect of the present disclosure, which may be combined with any other aspect enumerated herein, the software application is further configured, for (ii), to update at least one data field of the selected user interface with the received updated medical data and create a screen progression video using the user interface associated with the timestamp and the user interface associated with the second timestamp.

[0023] In a sixth aspect of the present disclosure, which may be combined with any other aspect enumerated herein, the software application includes options for playing the screen progression video, fast-forwarding the screen progression video, rewinding the screen progression video, slowing down the playback speed of the screen progression video, or skipping to the next alarm or event provided in the screen progression video.

[0024] In a seventh aspect of the present disclosure, which may be combined with any other aspect enumerated herein, the software application is further configured to send the request message to the server after the medical procedure is completed.

[0025] In an eighth aspect of the present disclosure, which may be combined with any other aspect enumerated herein, the medical data includes a data label, and the software application is configured to input the received medical data into the at least one data field of the selected user interface by matching the data label of the medical data with the at least one data field of the selected user interface.

[0026] In a ninth aspect of the present disclosure, which may be combined with any other aspects enumerated herein, the server is configured to store the identifier of the screen displayed by the medical device and the medical data shown on the screen in a medical record associated with the patient, the medical record including an identifier of the patient, an identifier of the medical device, and medical procedure session information. The request message includes at least one of the identifier of the patient, the identifier of the medical device, or the medical procedure session information. The request message causes the server to select the identifier of the screen displayed by the medical device and the medical data shown in the screen for transmission to the software application.

[0027] In a tenth aspect of the present disclosure, which may be combined with any other aspect enumerated herein, the medical device includes at least one of a hemodialysis machine, a hemodiafiltration machine, a large volume infusion pump, a syringe pump, a patient-controlled analgesia pump, a parenteral nutrition pump, a peritoneal dialysis machine, a continuous renal replacement therapy (CRRT) machine, a ventilator, a physiological monitor / sensor, or a patient bedside monitor.

[0028] In an eleventh aspect of the present disclosure, which may be combined with any other aspect listed herein, the server is a cloud-based server or is located within a medical facility.

[0029] In a twelfth aspect of the present disclosure that may be combined with any other aspect listed herein, the medical data includes at least one of ultrafiltration (UF) volume, treatment time, concentrate type, sodium concentration, bicarbonate concentration, heparin bolus volume, heparin flow rate, heparin stop time, heart rate, dialysis fluid temperature, dialysis fluid flow rate, dialysis fluid conductivity, UF profiling data, sodium profiling data, bicarbonate profiling data, blood flow rate to the dialyzer, pre-infusion and post-infusion volumes, and an indication as to whether UF is isolated, an indication as to whether a single needle is used for arterial and venous connections, an event, an alarm, or diagnostic information.

[0030] In a thirteenth aspect of the present disclosure, which may be combined with any other aspect enumerated herein, at least one of the non-input user interfaces is an overlay user interface displayed over another user interface.

[0031] In a fourteenth aspect of the present disclosure, which may be combined with any other aspect listed herein, the medical device is configured to receive physiological data from at least one sensor and include the physiological data together with the medical data.

[0032] In a fifteenth aspect of the present disclosure, which may be combined with any other aspect listed herein, the server is configured to receive physiological data from at least one sensor and include the physiological data together with the medical data.

[0033] In a sixteenth aspect of the present disclosure that can be combined with any other aspect listed herein, a system for remotely viewing medical data displayed on a screen of a medical device includes a user device including a processor and a memory, the memory storing instructions that, when executed by the processor, cause the processor to operate a software application including a plurality of unpopulated user interfaces corresponding to a plurality of different screens of the medical device. Each user interface includes at least one data field corresponding to a subset of medical data associated with the associated screen. The system also includes a server communicatively connected to the medical device and the user device via a network. The server is configured to receive from the medical device an identifier of a screen displayed by the medical device, the medical data shown on each screen in connection with a medical procedure for a patient, and a timestamp of when the medical data was displayed, generated, or transmitted. After receiving a request message from the software application of the user device, the server is configured to transmit the identifier of the screen, the corresponding medical data, and the associated timestamp, and cause the software application to select an unfilled user interface corresponding to the identifier of the screen, fill in the received medical data into the at least one data field of the selected user interface, arrange the user interfaces in order based on the timestamp, and present the user interfaces in a video-like sequential order to replay the medical procedure.

[0034] In a seventeenth aspect of the present disclosure, which may be combined with any other aspect enumerated herein, the software application is configured to send the request message to the server after the medical procedure is completed.

[0035] In an eighteenth aspect of the present disclosure, which may be combined with any other aspect enumerated herein, the server is configured to store the identifier of the screen, the medical data, and the corresponding timestamp in a medical record including at least one of an identifier of the patient, an identifier of the medical device, and medical procedure session information. The request message includes at least one of the identifier of the patient, the identifier of the medical device, or the medical procedure session information. The request message causes the server to select the identifier of the screen, the medical data, and the corresponding timestamp for transmission to the software application.

[0036] In a nineteenth aspect of the present disclosure that can be combined with any other aspect enumerated herein, a system for remotely viewing a screen of a medical device includes a medical device for performing a medical procedure on a patient, the medical device including a display device configured to display a medical procedure screen including medical data, a processor configured to record an image of the medical procedure screen and compress the image, and a digital communication module configured to receive the compressed image, decompress the image, and transmit the image to a server for storage in a memory device. The system also includes a user device including a processor and a memory, the memory storing instructions that, when executed by the processor, cause the processor to operate a software application. The system further includes a server communicatively connected to the medical device and the user device via a network. The server is configured to receive the image from the digital communication module and, after receiving a request message from the software application on the user device, transmit the image and cause the software application to display the image.

[0037] In a twentieth aspect of the present disclosure, which may be combined with any other aspect enumerated herein, the processor of the medical device is configured to receive a remote view input and record the image of the medical procedure screen after receiving the remote view input.

[0038] In a twenty-first aspect of the present disclosure, which may be combined with any other aspect enumerated herein, the processor is configured to, after the remote view input is received, display at least one of an IP address or a password, and transmit the at least one of the IP address or the password to the server for evaluating the image, and the software application is configured to display a prompt for the at least one of the IP address or the password to access the image associated with the medical device.

[0039] In a 22nd aspect of the present disclosure, which may be combined with any other aspect listed herein, the processor of the medical device is configured to associate a timestamp with the recorded image.

[0040] In a 23rd aspect of the present disclosure, which may be combined with any other aspect listed in this specification, the processor associates the timestamp with the recorded image by at least one of storing the timestamp as metadata of the image, displaying a watermark of the timestamp on the image, or storing the timestamp together with the image in the memory of the medical device.

[0041] In a 24th aspect of the present disclosure, which may be combined with any other aspect recited herein, the processor is further configured to record a next image of the medical procedure screen every 1 second to every 30 seconds, associate a timestamp with each next image, and compress the next image. The digital communication module is configured to decompress the next image and transmit the next image to the server. The server further transmits the next image to the software application, causes the software application to order the next images based on their respective timestamps, and displays the ordered next images.

[0042] In a 25th aspect of the present disclosure, which may be combined with any other aspect enumerated herein, the processor is further configured to record a next image of the medical procedure screen when a new medical procedure screen is displayed or when at least a portion of the medical data changes, associate a respective timestamp with the next image, and compress the next image. The digital communication module is configured to decompress the next image and transmit the next image to a server. The server further transmits the next image to the software application, causes the software application to order the next images based on the respective timestamps, and displays the ordered next images.

[0043] In a 26th aspect of the present disclosure, which may be combined with any other aspect enumerated herein, the server is a virtual network computing (VNC) server and the software application is a VNC viewer application.

[0044] In a 27th aspect of the present disclosure that can be combined with any other aspect listed herein, the system further includes a camera configured to record a camera image of the medical procedure screen and transmit the camera image to the server, the server configured to transmit the camera image to the software application, and cause the software application to display the camera image together with the image of the medical procedure screen created by the medical device.

[0045] In a 28th aspect of the present disclosure, which may be combined with any other aspect enumerated herein, at least one of the server or the software application is configured to compare the camera image with the image of a postponed medical procedure screen created by the medical device, and if the camera image does not match the image of the medical procedure screen created by the medical device, provide an audible and / or visual indication that the image of the medical procedure screen created by the medical device is incorrect.

[0046] In a 29th aspect of the present disclosure, which may be combined with any other aspect enumerated herein, at least one of the server or the software application is configured to perform the comparison using optical character recognition or pixel analysis.

[0047] In a thirtieth aspect of the present disclosure that may be combined with any other aspect enumerated herein, the medical device is configured to display a barcode on the medical procedure screen, the camera image is configured to include the barcode, and the at least one of the server or the software application is configured to perform the comparison by comparing the barcode in the image recorded by the medical device with the barcode included in the camera image.

[0048] In a thirty-first aspect of the present disclosure, which may be combined with any other aspect listed herein, the medical device is configured to periodically update the barcode.

[0049] In a thirty-second aspect of the present disclosure, any of the structures and functions disclosed in connection with Figures 1 to 12 may be combined with any of the other structures and functions disclosed in connection with Figures 1 to 12.

[0050] Therefore, in light of the present disclosure and the above aspects, it is an advantage of the present disclosure to provide a remote view of a screen of a medical device.

[0051] Another advantage of the present disclosure is that it transmits only the screen identifier and medical data shown on the screen of the medical device, allowing the software application on the clinician device to populate the corresponding user interface.

[0052] A further advantage of the present disclosure is the transmission of recorded images of the medical device screen for viewing in a software application on the clinician device.

[0053] Additional features and advantages are described in or will be apparent from the following detailed description and drawings. The features and advantages described herein are not all-inclusive, and in particular, many additional features and advantages will become apparent to those skilled in the art in view of the drawings and description. Moreover, any particular embodiment need not possess all of the advantages enumerated herein, and it is expressly contemplated that each advantageous embodiment may be separately claimed. Furthermore, it should be noted that the language used herein has been chosen primarily for readability and descriptive purposes, and not to limit the scope of the inventive subject matter. [Brief explanation of the drawings]

[0054] [Figure 1] FIG. 1 illustrates a diagram of a medical system having a cloud-based server, according to an exemplary embodiment of the present disclosure.

[0055] [Figure 2] FIG. 2 illustrates a diagram of a medical system having a medical center-based server, according to an exemplary embodiment of the present disclosure.

[0056] [Figure 3] FIG. 3 is a diagram illustrating how a user interface may be indexed on a memory device to allow the screen of a medical device to be viewed remotely, according to an exemplary embodiment of the present disclosure.

[0057] [Figure 4] FIG. 4 is an illustration of a user interface displayed by a software application on a clinician device according to an exemplary embodiment of the present disclosure.

[0058] [Figure 5] FIG. 5 is a diagram of another user interface displayed by a software application on a clinician device according to an exemplary embodiment of the present disclosure.

[0059] [Figure 6] FIG. 6 is an illustration of another user interface that may be displayed by a software application running on a clinician device according to an exemplary embodiment of the present disclosure.

[0060] [Figure 7] FIG. 7 illustrates a flow diagram of an exemplary procedure for providing a remote view replay of a treatment session using medical data, according to an exemplary embodiment of the present disclosure.

[0061] [Figure 8] FIG. 8 is a flow diagram of an exemplary procedure for providing a remote view replay of a treatment session using images, according to an exemplary embodiment of the present disclosure.

[0062] [Figure 9] FIG. 9 is a diagram of a medical system using VNC for remote screen viewing of medical devices, according to an exemplary embodiment of the present disclosure.

[0063] [Figure 10] , [Figure 11] 10 and 11 are diagrams of a medical device (e.g., an automated dialysis machine) for providing a screen for remote viewing, according to an exemplary embodiment of the present disclosure.

[0064] [Figure 12] FIG. 12 is an illustration of a medical system having a camera for providing verification of a remote screen view, according to an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0065] Disclosed are methods, systems, and apparatus for remote screen viewing of medical devices. The methods, systems, and apparatus are configured to provide real-time, near-real-time, and / or replayable views of a medical device on a remote clinician device. Such configurations allow a clinician to see how a medical device is currently operating or has previously operated to help diagnose problems with a patient's settings or treatment. The methods, systems, and apparatus provide a near-exact reproduction of what is displayed on the medical device to provide complex context for the medical data.

[0066] Clinicians are accustomed to working with medical devices and are familiar with the various screens. This familiarity allows them to quickly diagnose problems with medical devices. Exemplary methods, systems, and apparatus provide the clinician with the same information in the same context and graphical format while the clinician is located remotely from the medical device, thereby enabling the clinician to assess treatment issues as if the clinician were present at the patient's bedside. Such functionality helps improve patient care in home-based dialysis and remote areas, where a single clinician may be responsible for overseeing many different medical facilities. The remote view functionality disclosed herein overcomes the problem of known medical systems that simply display logs of medical device data, making it difficult to understand and identify trends.

[0067] The remote view feature described herein can also assist clinicians with less training or experience. Typically, when a clinician using a medical device for the first time begins setup or a procedure and encounters a problem, the clinician will typically contact the service desk to report the device issue. It can typically take 10 to 30 minutes to resolve the issue. Using the remote view feature disclosed herein, the service desk can obtain a real-time or near-real-time view of the medical device screen to help guide the clinician through the setup procedure or procedure. The service desk can see how the clinician changes the medical device screen and provide appropriate feedback.

[0068] The remote view feature also reduces the need for clinicians to enter a patient's room. This can be especially important for patients with infectious diseases such as Covid, where clinicians typically must wear protective masks and clothing to enter a patient's room. Instead of entering the patient's room, the remote view feature allows clinicians to view the same image as the medical device screen on their own mobile device or computer.

[0069] In addition to the above, the methods, systems, and apparatus are configured to create a screen progression video using a sequence of images or medical data from a medical device. The screen progression video allows a clinician to see how a medical device operated in the past before a problem was detected, thereby helping the clinician determine a possible root cause. For example, using the screen progression video, a clinician may notice that a patient's blood pressure began to slowly rise when heparin or another fluid was injected into the extracorporeal circulation circuit of an HD device. Because the increase in blood pressure was gradual, an hour or so may have passed before the blood pressure reached a threshold that triggered an alert. Known medical devices only show the current status of a procedure. In contrast to known medical devices, the present methods, systems, and apparatus allow a clinician to rewind the screen progression video to see what happened at the medical device when the patient's blood pressure began to rise. As described in more detail below, the screen progression video may be stored on the medical device, on a database, and / or on a software application running on the clinician device. The remote view functionality provided by the present methods, systems, and apparatus allows clinicians to view a near-exact copy of a medical device screen from virtually any location, thereby improving patient care even when the clinician cannot easily reach the patient's bedside.

[0070] References herein will be made to automated HD or HDF machines. It should be understood that the methods, systems, and apparatus may provide remote screen viewing for any type of medical device, including large volume infusion pumps, syringe pumps, patient-controlled analgesia pumps, parenteral nutrition pumps, PD machines, CRRT machines, ventilators, physiological monitors / sensors, and / or patient bedside monitors. Each of these medical devices includes a defined number of screens that allow software applications on the clinician device to input relevant medical data into corresponding user interfaces. Additionally, each of these medical devices may be configured to record and transmit screen images over a network for display on the clinician device.

[0071] As used herein, reference is made to medical data. As disclosed, medical data is generated in a medical device and available for transmission. The medical data includes treatment programming information. The treatment programming information includes one or more parameters that define how the medical device operates to administer treatment to a patient. In the case of peritoneal dialysis therapy, the parameters can specify the amount (or rate) of fresh dialysis fluid to be infused into the patient's peritoneal cavity, the amount of time the fluid should remain in the patient's peritoneal cavity (i.e., dwell time), and the amount (or rate) of spent dialysis fluid and ultrafiltration (UF) to be infused or drained from the patient after the dwell time has ended. In the case of treatment involving multiple cycles, the parameters can specify the fill volume, dwell volume, and drain volume of each cycle, as well as the total number of cycles to be performed during the course of treatment (either one treatment per day or separate treatments provided during the day and night). In the case of CRRT, the parameters can include a continuous UF rate. Additionally, the parameters can specify the date / time / day (e.g., schedule) on which the treatment is to be performed by the medical fluid delivery machine. Additionally, the parameters of a given therapy may specify the total volume of dialysis fluid to be administered for each treatment, as well as the concentration level of the dialysis fluid, such as glucose concentration. For infusion therapy, the parameters may include the volume to be infused, the drug to be infused, the drug concentration, the drug dosage, and / or the infusion rate.

[0072] For the Baxter International AK 98™ hemodialysis machine, treatment programming parameters can include UF volume, treatment time, concentrate type, sodium concentration, bicarbonate concentration, heparin bolus volume, heparin flow rate, heparin stop time, heart rate monitoring flag, dialysis fluid temperature, dialysis fluid flow rate, and indications of whether UF is isolated, whether UF profiling should be performed, whether a single needle is used for arterial and venous connections, whether sodium profiling should be performed, whether bicarbonate profiling should be performed, and / or whether dialysate conductivity monitoring should be performed. The blood flow rate to the dialyzer can also be a treatment programming parameter. For HDF, pre- and post-infusion volumes can also be treatment programming parameters.

[0073] The medical data also includes event information related to the administration of treatment. Event information may include data generated by a medical device indicating measured, detected, or determined parameter values. For example, a prescribed therapy may specify that the treatment is to include five separate cycles, each with a 45-minute dwell time, but the medical fluid delivery device may administer the treatment in which fewer cycles are provided, each with a 30-minute dwell time. The medical device monitors how the treatment is administered and therefore provides parameters indicative of operation. Parameters for treatment data may include, for example, the total amount of dialysis fluid administered to the patient, the number of cycles administered, the fill volume per cycle, the dwell time per cycle, the drain time / volume per cycle, the estimated amount of UF removed, the treatment start date and time, and / or the treatment end date and time. The treatment data may also include calculated parameters, such as the fill rate and drain rate, which are determined by dividing the amount of fluid infused by the time spent infusing. The procedure / event data may further include an identification of any alarms that occurred during the procedure, the duration of the alarm, the time of the alarm, the event associated with the alarm, and / or an indication as to whether the problem that caused the alarm was resolved or whether the alarm was silenced.

[0074] The medical data further includes device machine logs, including diagnostic information, failure information, etc. Diagnostic information can include information indicative of the internal operation of the medical device, such as faults related to pump operation, signal errors, communication errors, software problems, etc. Diagnostic information may also include configuration information, such as steps taken to connect tubing to the medical device and prime / disinfect the tubing. The medical data may be transmitted as a data stream or provided at periodic intervals. In some cases, the medical data may be transmitted when an event occurs or when some change in the data occurs.

[0075] Methods, systems, and apparatus are described within the context of providing a remote view of a medical device screen. In some embodiments, the remote view functionality may be provided in conjunction with remote control of the medical device. For example, an application on a clinician device may display a medical device screen disclosed herein. The application may also provide inputs related to the displayed screen that allow the clinician to modify the operation of the medical device. In some examples, the inputs may be similar to or identical to inputs displayed by the medical device screen. Selection of an input causes a corresponding command message to be sent to the medical device to provide remote control. I. Medical Data Remote Viewing Embodiment

[0076] FIG. 1 shows a diagram of a medical system 100 according to an exemplary embodiment of the present disclosure. The exemplary medical network system 100 includes three medical devices 102, 104, and 106 (e.g., automated dialysis machines). The automated dialysis machine 102 may be an Amia automated PD system manufactured by Baxter® International Inc. The automated dialysis machines 104 and 106 may be PrisMax CRRT machines manufactured by Baxter International Inc. In other embodiments, the system 100 may include additional or fewer medical devices. For example, the system 100 may include an intermediate hemodialysis machine, an infusion pump (e.g., a syringe pump, a linear peristaltic pump, a large volume pump (LVP), an ambulatory pump, a multi-channel pump), a nutrient blender, a water preparation machine, etc. The system 100 may also include a bedside patient monitor or physiological sensor, such as an oxygen sensor, a respiratory monitor, a glucose meter, a blood pressure monitor, an electrocardiogram (ECG) monitor, a weight scale, a heart rate monitor, or any other peripheral medical device configured to sense a patient's physiological parameters.

[0077] The automated dialysis machines 102-106 can be located in a patient's home or in a medical facility. For example, the automated dialysis machine 102 can be located in a patient's home, while the automated dialysis machines 104 and 106 are located in a medical facility. FIG. 1 shows the automated dialysis machines 102-106 communicatively coupled to a server 108 via one or more networks. The server 108 can be a cloud-based system that includes one or more distributed memory devices 109.

[0078] The automated dialysis machines 102-106 are configured to accept one or more parameters that specify a treatment or prescription (i.e., treatment programming information). During operation, the automated dialysis machines 102-106 generate event data, diagnostic data, and / or operational data (e.g., medical data). In some embodiments, the medical data conforms to the ISO / IEEE 11073™ standard as XML-based information objects. In other embodiments, the medical data is in a different format, such as JavaScript Object Notation (JSON), HyperText Markup Language (HTML), comma-separated values ​​(CSV), text, and / or Health-Level-7 (HL7).

[0079] For brevity, only the components of the automated dialysis machine 106 are described below. However, it should be understood that the same or similar components may be included in the automated dialysis machines 102 and 104. Such components are independent of the type of medical device.

[0080] In the depicted example, the automated dialysis machine 106 includes a display device 110 that displays one or more screens 112 that provide graphical representations of medical data, or more generally, the status of a patient's treatment or settings. The display device 110 may include a touch screen configured to receive input. Additionally or alternatively, the display device 110 may include a control interface 114 that allows a clinician to select options shown on the screens 112. The control interface 114 may include buttons on the display device 110, a control panel, or a touch screen. The control interface 114 may also be configured to allow a clinician to navigate to a particular screen 112 for viewing. The control interface 114 may also provide instructions for operating or controlling the automated dialysis machine 106.

[0081] The automated dialysis machine 106 also includes a memory device 116 configured to store the screens 112. The automated dialysis machine 106 has a number of current screens and pop-up windows that can be displayed. For example, the automated dialysis machine 106 may have 20 or 30 different screens 112 for treatment settings, alerts, and treatment types. Furthermore, in some embodiments, multiple screens may be displayed, with at least some screens overlaid on other screens. When multiple screens are used, the automated dialysis machine 106 may identify the stacking and / or positioning of the screens to enable the user interface provided to the clinician device to be arranged in a similar manner. Each screen 112 is assigned an identifier. Furthermore, each screen includes data fields that specify which medical data generated by the automated dialysis machine 106 should be displayed within a particular section of the screen 112. The data fields may specify data labels or other identifiers used to match and determine which data fields should contain the labeled medical data. The memory device 116 may include any RAM, ROM, EEPROM, flash drive, solid-state drive, distributed database, etc.

[0082] The automated dialysis machine 106 further includes a processor 118 communicatively connected to the display device 110, the control interface 114, and the memory device 116. The processor 118 is configured to generate and / or process medical data 120 that is stored in the memory device 116. The processor 118 determines which subset of the medical data 120 should be displayed on the screen 112 of the automated dialysis machine 106. The processor 118 may generate and process the medical data 120 in HL7 format, XML format, binary version 2 format, binary version 3 format, or Fast Healthcare Interoperability Resources (FHIR) format.

[0083] As described above, the medical data 120 of the automated dialysis machine 106 may include UF volume, treatment time, concentrate type, sodium concentration, bicarbonate concentration, heparin bolus volume, heparin flow rate, heparin stop time, heart rate monitor flag, dialysis fluid temperature, dialysis fluid flow rate, and indicators regarding whether UF is isolated, whether UF profiling should be performed, whether a single needle is used for arterial and venous connections, whether sodium profiling should be performed, whether bicarbonate profiling should be performed, and / or whether dialysis fluid conductivity monitoring should be performed. The medical data 120 may also include blood flow rate to the dialyzer, as well as pre- and post-infusion volumes. Additionally, the medical data 120 may include events and / or alarms, such as priming information, line connection / disconnection information, disinfection / cleaning information, occlusion detection, significant pressure or flow fluctuations or changes, etc. The processor 118 operates one or more pumps or other components to perform treatment and generates the medical data 120. The medical data 120 may further include a prescription value for the total treatment time that the patient should receive blood treatment, a prescription value for the total patient fluid removal that should be achieved by the end of the total treatment time, and a prescription value for the average patient fluid removal rate that should be maintained over the total treatment time.

[0084] In some embodiments, one or more physiological sensors may be communicatively connected to one of the automated dialysis machines 102-106. For example, FIG. 1 shows a physiological sensor 124 connected to a home-based automated dialysis machine 102. The sensors 124 may include an oxygen sensor, a respiratory monitor, a glucose meter, a blood pressure monitor, an electrocardiogram (ECG) monitor, a weight scale, a heart rate monitor, etc. The processor 118 of the automated dialysis machines 102-106 may be configured to include data from the physiological sensors as medical data 120 transmitted to the server 108, as a portion of the screen 112 may include data fields for the patient's physiological data measured by one or more sensors.

[0085] The processor 118 of the automated dialysis machine 106 operates according to one or more instructions to perform treatment on a patient, which instructions may be obtained via the control interface 114 or via the memory device 116. The processor 118 also monitors the device components for issues that are documented as diagnostic medical data 120. Although the automated dialysis machine 106 is shown as having one processor 118, as discussed below, in some embodiments, the automated dialysis machine 106 may include two or more processors 118 with designated operations.

[0086] The automated dialysis machines 102-106 are communicatively connected to the server 108 via one or more network connections. In the case of the home-based automated dialysis machine 102, the network connections may include any combination of an Ethernet connection, an Internet connection, a Wi-Fi connection, a wireless local area network (WLAN), and / or a cellular 5G / 6G connection. In the case of the facility-based automated dialysis machines 104 and 106, the network connections may include any combination of an Ethernet connection, a Wi-Fi connection, a WLAN connection, a LAN connection, etc. The network connections may include one or more of an access point, a router, a repeater, or other telecommunications equipment for routing communications in the network.

[0087] In the illustrated example, the server 108 is configured to store medical data 120 from the automated dialysis machines 102-106. The medical data 120 may be transmitted periodically or whenever at least a portion of the medical data 120 changes. The server 108 stores the medical data 120 in a memory device 109 and enables remote access by the clinician devices 130 and 132. Such a configuration prevents the clinician devices 130 and 132 from directly accessing the automated dialysis machines 102-106. In some embodiments, the memory device 109 may also store blank user interfaces 136 corresponding to different screens 112 of the automated dialysis machines 102-106.

[0088] 1 illustrates an example in which the server 108 is provided in a cloud-based network. To transmit the medical data 120, the automated dialysis machines 102-106 can authenticate with the server 108 and transmit using a secure internet communication protocol. The automated dialysis machines 102-106 can be configured to transmit the medical data 120 to one or more destination addresses corresponding to one or more application programming interfaces (APIs) of the server 108. The server 108 and the memory device 109 can both include a network of servers and memory devices configured within a distributed framework. In some examples, the server 108 and the memory device 109 can be hosted by Amazon® Web Services (AWS).

[0089] The server 108 is configured to store the medical data 120 in the memory device 109 by patient identifier and / or machine identifier / address. For example, a message with the medical data 120 from the automated dialysis machines 102-106 may include the patient identifier and / or machine identifier / address. The server 108 uses the identifier / address to index and store the medical data 120 in the appropriate location in the memory device 109, so that the clinician devices 130 and 132 can access the medical data 120 by providing the corresponding patient or machine identifier after authentication.

[0090] In contrast to Figure 1, Figure 2 shows a medical system 200 that includes a server 201 that may be located within a medical facility. The medical system 200 also includes a memory device 204 that is centrally located relative to the server 201. In some examples, the server 201 may include a VNC server.

[0091] In the example of Figure 2, automated dialysis machines 104 and 106 may be connected to server 201 through one or more gateways, routers, and / or switches that form part of a LAN. Home-based automated dialysis machine 102 instead connects to server 201 through a firewall to the LAN. In either embodiment, medical systems 100 and 200 of Figures 1 and 2, respectively, allow medical data 120 to be transmitted from automated dialysis machines 102-106 to a server for storage on a memory device, regardless of the network location of the server and memory device.

[0092] Returning to Figure 1, the medical system 100 includes clinician devices 130 and 132 for accessing the medical data 120 stored in the memory device 109. The clinician devices 130 and 132 may include smartphones, tablet computers, laptop computers, desktop computers, workstations, and clinician stations. While Figure 1 shows two clinician devices 130 and 132, it should be understood that the medical system 100 may include multiple clinician devices connected to the server 108 via a local or wide area network.

[0093] For brevity, only the clinician device 130 will be described. However, the foregoing disclosure of the clinician device 130 also applies to the other clinician devices 132. The clinician device 130 includes a processor 140 and a memory device 142. Instructions are stored on the memory device 142. Execution of the instructions by the processor 140 causes the processor 140 to operate a software application 144 to perform the operations described herein. The processor 140 may comprise digital and / or analog circuitry configured as a microprocessor, an application specific integrated circuit (ASIC), a controller, or the like. The memory device 142 includes a volatile or non-volatile storage medium. Additionally, the memory device 142 may include a solid-state or disk storage medium.

[0094] The software application 144 is configured to store the unpopulated user interface 136 in the memory device 142. As described below, local storage of the user interface 136 allows the software application 144 to select, populate, and display the user interface 136 after receiving a screen identifier and corresponding medical data 120 from the server 108. In other embodiments, the server 108 transmits the corresponding user interface 136 when the medical data 120 is transmitted to the software application 144 on the clinician device 130, thereby eliminating the need for local storage of the user interface.

[0095] To provide a remote view of the medical data 120, the automated dialysis machines 102-106 transmit the generated or created medical data 120 to the server 108, as shown in Event A. The medical data 120 includes, for example, a screen identifier for the screen 112 displayed by the display device 110 of the automated dialysis machine 106. The medical data 120 also includes the medical data 120 shown in the screen 112 (which is a subset of all generated medical data) determined by the processor 118. The medical data 120 may include prescription information, flow rate, pressure, alarm identifiers, etc. The medical data 120 may also include a timestamp corresponding to when the medical data 120 was generated or displayed in the screen 112. The medical data 120 may further include key press information and / or screen overlay information (e.g., an alarm dialog box located on top of a treatment screen) related to the operation of the control interface 114. The medical data 120 may also include a patient or machine identifier.

[0096] The automated dialysis machine 106 may be configured to transmit the medical data 120 periodically, such as every 1 second, every 2 seconds, or every 30 seconds. Alternatively, the processor 118 of the automated dialysis machine 106 is configured to transmit only the medical data 120 shown on the screen 112 when the data changes. In yet another embodiment, the automated dialysis machine 106 is configured to transmit all of the medical data 120 shown on the screen 112 whenever the data changes. As a default, the processor 118 may be configured to transmit the medical data 120 every 30 minutes, for example, when there is a change in the medical data value shown on the currently displayed screen 112. It should be understood that regardless of which transmission method is used, the size of the transmitted information is only a few bytes.

[0097] In event B, the server 108 stores the medical data 120 based on the patient or machine identifier. The server 108 may store the medical data 120 in the patient's EMR, which is stored in a data structure or database in the memory device 109. The server 108 is configured to continuously store newly received medical data 120 so that previous medical data 120 is not overwritten.

[0098] 1 , the software application 144 on the clinician device 130 first authenticates with the server 108. After authentication, the software application 144 sends a request message to the server 108. The request message includes, for example, a patient or machine identifier to enable the server 108 to locate corresponding medical data 120 stored in the memory device 109. The request message may alternatively specify a treatment session and / or date. In some embodiments, the software application 144 operates in conjunction with the server 108 to provide selectable and filterable lists of patients, treatment sessions, and / or medical devices for a given patient, treatment date, care area, etc.

[0099] The request message causes the server 108 to identify and transmit the requested medical data 120 to the software application 144. The server 108 also transmits the corresponding screen identifier, timestamp, keypress information, screen overlay information, and parameters that are part of the medical data 120. The software application 144 uses the screen identifier to select a corresponding unentered user interface 136 stored in the memory device 142. Each unentered user interface 136 is provided in an indexed array in the memory device 142 based on the identifier, which allows the software application 144 to quickly determine which user interface is needed based on the received screen identifier. The software application 144 then enters the medical data 120 into the data fields of the selected user interface 136 to provide a live or near-live view of the screen 112 of the automated dialysis machine 106.

[0100] In some embodiments, the screen identifier may include or correspond to a version number. When a new version of a screen is created, the server 108 and / or software application 144 may also receive the updated corresponding user interface 136. The incorporation of the version number ensures that the appropriate user interface 136 is selected despite software updates and releases.

[0101] Additionally, in some embodiments, the screen identifier may include or take into account the language. For example, the screen identifier may include a prefix or suffix that specifies the language. This may ensure that a user interface 136 in the appropriate language is selected.

[0102] If multiple screens are shown together and / or overlaid on each other, multiple screen identifiers are transmitted. The automated dialysis machine 106 can include the screen layer and / or screen position location in the message with the screen identifier. Such information is used by the server 108 and / or software application 144 to select, arrange, and position the corresponding user interface 136.

[0103] FIG. 3 is a diagram illustrating how user interfaces 136 may be indexed on memory devices 109 and 142, according to an exemplary embodiment of the present disclosure. In the illustrated example, each unentered user interface 136 includes a screen identifier and a corresponding name. Each unentered user interface 136 includes one or more data fields 302 that identify which medical data 120 should be written thereto. In some embodiments, the medical data 120 includes a data label or identifier that specifies the type of each data value. In these embodiments, the software application 144 matches the identifier of the data field 302 with the data label of the medical data 120 to determine which medical data 120 should be written to that data field. In other embodiments, the order in which the medical data 120 is received specifies the data type used to match it to the appropriate data field 302.

[0104] Each of the data fields 302 may specify a location on the user interface 136 where the medical data 120 is displayed. The data fields 302 may further specify a font size, font type, font color, and any other information for properly rendering the medical data 120, for example, to match or approximate the way the medical data is presented on the screen 112 of the automated dialysis device 106.

[0105] 3, data fields 302a and 302b may be single value fields that specify that a single numeric value should be displayed. In contrast, data field 302c includes one or more rules 304 that specify how a graphical element in user interface 136 should be adjusted based on the value of the corresponding medical data 120. Rules 304 may be used for gauges, graphs, meters, or other variable graphical elements of user interface 136.

[0106] In the illustrated example, software application 144 determines that screen ID 5 should be rendered. Software application 144 also determines to display overlay screen 51. Using medical data 144 received or otherwise fetched from server 108, software application 144 displays alarm dialog user interface 136a overlaid on treatment 1 user interface 136 to match that shown on display device 110 of automated dialysis machine 106.

[0107] Key presses on the control interface 114 are not shown on the screen 112 of the automated dialysis device 106. However, the software application 144 may provide a graphical representation of the control interface 114 and highlight or provide an audio indication when buttons are pressed. The graphical representation of the control interface 114 may be provided adjacent to the displayed user interface 136.

[0108] FIG. 4 is a diagram of a Therapy 1 user interface 136 displayed by a software application 144 on a clinician device 130, according to an exemplary embodiment of the present disclosure. The illustrated user interface 136 represents the screen 112 displayed on an automated dialysis machine 106. The user interface 136 includes multiple data fields 302, such as data fields 302a and 302b, indicating respective infusion and blood pump speeds or blood flow rates. The blank user interface includes graphics, while the software application 144 adds values ​​from the medical data 120. Data field 302c includes displayed values ​​in addition to graphical elements that can change based on the values ​​of the medical data. Specifically, the diagram shows patient fluid removal volumes corresponding to fluid removal rates. As the volume increases, a rule 304 for the data field 302 specifies that the container graphical element should appear larger. The rule 304 may include a correlation between the removed volume and the displayed fluid height.

[0109] 4 includes other data fields including single value displays, graphs, gauges, etc. A software application 144 inputs each of the data fields and adjusts the variable graphics so that the input user interface appears substantially identical to the screen 112 of the automated dialysis machine 106.

[0110] FIG. 5 is a diagram of another user interface 136b displayed by the software application 144 of the clinician device 130, according to an exemplary embodiment of the present disclosure. The user interface 136b is an overlay displayed on top of the user interface 136 displayed in connection with FIG. 4. At this point, the user may press a button on the control interface 114 to pause or stop the treatment, which causes an overlay screen to be displayed by the automated dialysis machine 106. An identifier for the overlay screen is transmitted from the automated dialysis machine 106 to the server 108 and stored in the appropriate EMR in the memory device 109. Additionally, an indication of which button was pressed, a timestamp of the action, and any corresponding medical data 120 are also transmitted. The software application 144 determines that an overlay screen is to be displayed based on the received screen identifier and, therefore, selects the corresponding overlay user interface 136b. It should be understood that while a user of the automated dialysis machine 106 can select any of the options in the overlay screen, a clinician using the software application 144 cannot select options and can only view the user interface 136b.

[0111] 6 is another user interface 600 that may be displayed by a software application 144 running on a clinician device 130, according to an exemplary embodiment of the present disclosure. Here, the user interface 600 includes a section for displaying the user interface 136 representing the screen 112 of the automated dialysis machine 106. In addition, the user interface 600 includes a section 602 for viewing a summary of the medical data 120, which may be organized into separate categories. The user interface 600 also includes a section 604 that shows a graphical view of the automated dialysis machine 106 to provide the clinician with some additional context.

[0112] The above description provides a current view of the screen 112 of the automated dialysis machine 106. As new medical data 120 is generated and stored in the memory device 109, the software application 144 fetches the new data 120 to update the user interface 136. Additionally, when a new screen 112 is to be displayed on the display device 11, the software application 144 receives a new screen identifier from the server 108 to render the appropriate user interface 136.

[0113] In addition to the current view, the software application 144 and server 108 use the timestamps to create a screen progression video from the sequence of displayed user interfaces 136. Because each instance of medical data 120 is timestamped, a separate instance of user interface 136 can be created. The sequence of user interfaces 136 can be combined into a video-type playback that allows the clinician to pause, rewind, fast forward, etc., using the software application 144 to view the progression of a setup or procedure.

[0114] If the clinician selects to view a procedure or setup already in progress, the software application 144 and / or server 108 are configured to build a screen progression video 146 as the user interface 136 updates over time. Additionally, the software application 144 and / or server 108 may be configured to retrieve medical data 120 (and corresponding timestamps, screen identifiers, etc.) that was generated before the clinician made the remote view request. Thus, the software application 144 and / or server 108 backfills the setup or procedure steps, allowing the clinician to rewind to view the entire progression up to the current point.

[0115] Returning to FIG. 1 , the clinician device 132 can request to view an already completed treatment. The clinician device 132 sends a request message with a treatment session identifier, a patient identifier, and / or a machine identifier. In response, the server 108 fetches medical data 120 (including timestamps, screen identifiers, button presses, etc.) associated with the requested session. The server 108 sends the medical data 120 to a software application on the clinician device 132, which then inputs the user interface 136 accordingly to generate a screen progression video 146. In some embodiments, the video 146 is a series of images (a sequence of images) of the user interface 136 as it changes over time. In other embodiments, the video 146 is a sequence of the user interface 136 itself for each timestamp in the medical data 120. In either case, the screen progression video 146 allows the clinician to review how the dialysis setting or treatment progressed.

[0116] In some examples, the server 108 can create the screen progression video 146 on behalf of the software application 144. In these examples, the server 108 creates the screen progression video 146 after receiving a request message with a treatment session, patient, and / or machine selection. The server 108 then transmits the screen progression video 146 for display on the clinician device 132, for example.

[0117] FIG. 7 illustrates a flow diagram of exemplary procedures 700 and 750 for providing a remote view replay of a treatment session, according to an exemplary embodiment of the present disclosure. While procedures 700 and 750 are described with reference to the flow diagram illustrated in FIG. 7 , it should be understood that many other methods of performing the steps associated with procedures 700 and 750 may also be used. For example, the order of many of the blocks may be changed, some blocks may be combined with other blocks, and many of the described blocks may be optional. For example, a clinician may instead choose to view the current settings or treatment rather than replay an already completed procedure. The operations described in procedure 700 may be specified by one or more instructions and may be performed among multiple devices, including, for example, the server 108 and / or the automated dialysis machines 102-106. The operations described in procedure 750 may be specified by one or more instructions in a software application 144 and may be performed among multiple devices, including, for example, the server 108 and / or the clinician device 130.

[0118] The exemplary procedure 700 begins when the automated dialysis machine 106 initializes or starts up (block 702). The automated dialysis machine 106 remains idle until a clinician or other user initiates treatment setup (block 704). The automated dialysis machine 106 then determines whether new medical data 120 has been generated (block 706). If new medical data 120 has been generated, the automated dialysis machine 106 transmits the newly generated medical data 120, including screen identifiers, dialysis parameters, timestamps, button presses, patient identifiers, etc., to the server 108 for storage in the appropriate patient EMR in the memory device 109 (block 708). After setup is complete and treatment or procedure has begun (block 710), the automated dialysis machine 106 determines whether new medical data 120 has been generated (block 712). If new medical data 120 is generated, the automated dialysis machine 106 sends the newly generated medical data 120, including screen identifiers, dialysis parameters, timestamps, button presses, patient identifiers, etc., to the server 108 for storage in the appropriate patient EMR in the memory device 109 (block 708). The automated dialysis machine 106 then checks whether to continue treatment (block 714). If treatment is to continue, the automated dialysis machine 106 continues to send the newly generated medical data 120 to the server 108 until treatment is completed (block 716). The example procedure 700 then ends.

[0119] The exemplary procedure 750 begins when the software application 144 is opened or launched (block 752). The software application 144 may display a list of available automated dialysis machines and / or other medical devices (block 754). The software application 144 may allow a user to enter a dialysis machine identifier (e.g., serial number), treatment date and / or duration (e.g., start and end dates), and / or patient identifier (blocks 756 and 758). The software application 144 sends a request message to the server 108 using filter criteria or selections of patients, medical devices, treatment sessions, etc. (block 760). The request message is used to fetch medical data 120 from the memory device 109 via the server 108 (block 762), including screen identifiers, timestamps, button presses, etc.

[0120] The software application 144 then creates a screen progression video 146 by entering the associated medical data 120 into the user interfaces 136 that correspond to the associated screen identifiers for each timestamp (block 764). The software application 144 then arranges the user interfaces 136 in an order based on the timestamps to create the screen progression video 146. In some examples, the software application 144 may also record videos of the progression through different interfaces to create native video files for viewing the treatment progression.

[0121] The clinician then views the screen advance video 146, which may include options to pause, play, fast forward, rewind, and change the playback speed (block 766). In some examples, the screen advance video 146 has an option to play until an event occurs at which point the screen advance video 146 is paused. The software application 144 may also include a scroll bar that the clinician can drag to reach a particular point during the procedure. In some examples, an icon or other graphical element is displayed in conjunction with the scroll bar to indicate the time location of an event / alarm / alert during the procedure. The following is a summary of the possible video modes provided by the software application 144: a) Autorun-Pause-Run (Pause when event occurs) In this mode, the video will play automatically. The video will automatically stop at every event (alarm, alert, error, screen change, etc.), pause for a few seconds, and then run again. The timestamp appears as a watermark on top of the video or in the scroll bar. b) Manual Run - Pause - Run Pause Run (Pause on Event) The video starts playing and pauses when an event occurs (alarm, alert, error, screen change, etc.), but the user must tap the screen to keep the video playing (this gives the user time to review the screen). The timestamp appears as a watermark on top of the video or in the scroll bar. c) Snapshot of selected events (showing only setup screens, treatment screens, recirculation, etc.): This option allows the user to select one or more events (eg, access pressure rise or blood leak alarm). In this mode, the video has only the selected event screen with the timestamp in the scrollbar or as a watermark. The video stops at each event and continues when you tap the screen. d) Snapshot of selected phase (showing only setup screen or treatment screen or recirculation etc.): This option allows the user to select whether they want to see only the treatment screen or the settings screen. e) Fast forward and stop at the selected event. In this option, the video plays as a fast forward video but stops at the event selected by the user.

[0122] After the clinician has finished viewing the screen progression video 146, the example procedure 750 ends. II. Screen Image Remote View Embodiments

[0123] In the above-described embodiments, the software application 144 is configured to input medical data into a user interface. In the embodiments described below, the medical device is configured to transmit images of the displayed screen. While these embodiments may use more bandwidth to transmit images instead of medical data, they use less processing because the medical data does not need to be entered into one or more user interfaces by a software application running on the clinician device. As with the previous embodiment, the medical device can transmit timestamps along with the screen images to allow for the creation of a progressing video of the screen, thereby enabling replay of a medical procedure, such as a dialysis procedure.

[0124] Returning to FIG. 2 , the medical system 200 shows the automated dialysis machine 106 generating images 202 of the screen 112 shown by the display device 110. The images 202 may be recorded using a screen capture operation. Each image 202 may be in JPEG, PNG, BMP, TIFF, or other image file format. The automated dialysis machine 106 may generate the images 202 periodically, such as every second, every two seconds, every ten seconds, every thirty seconds, or every five minutes. Alternatively, the automated dialysis machine 106 may be configured to create an image 202 when at least a portion of the medical data 120 on the screen 112 changes or a different screen is shown. The automated dialysis machine 106 also generates a timestamp when the image 202 is generated. The timestamp may be stored in the image 202 (e.g., in the image file) as metadata, written onto the image as a watermark, or stored in association with the image 202 in the memory device 116.

[0125] 2, after the image 202 is generated, the automated dialysis machine 106 transmits the image 202 (and corresponding timestamp) to the server 108 for storage in the patient's electronic medical record in the memory device 109. The image 202 may be stored in a record, file, or data structure that identifies the patient, treatment session, and / or the automated dialysis machine 106 for retrieval by the software application 144. In some examples, the automated dialysis machine 106 compresses the image 202, which is transmitted to the server 108 for decompression and storage. In other embodiments, the image 202 is transmitted uncompressed.

[0126] In addition to the timestamp, the automated dialysis machine 106 may also store information indicating an alarm or event associated with the image 202. By including the alarm or event information, the software application 144 can fast-forward the progression or sequence of images 202 until the alarm or event is reached.

[0127] In the depicted example, the server 108 is shown as being located within a medical facility such that the automated dialysis machine 106 and the server 108 are both located behind a firewall as part of a local area network. In these embodiments, the image 202 may not be encrypted. Additionally, the automated dialysis machine 106 may not need to authenticate with the server 108 since both are part of a trusted network. Similar to timestamps, alarm or event information may be stored as metadata in the image 202, overlaid as a watermark, or stored in association with the image 202.

[0128] 1, the server 108 may be located off-site, such as in a cloud computing environment. In these embodiments, the automated dialysis machine 106 may need to authenticate with the server 108 before transmitting the images 202. Additionally, or alternatively, the automated dialysis machine 106 may encrypt or otherwise secure the images 202 for transmission.

[0129] After the server 108 stores at least one image 202, the software application 144 on the clinician device 130 can request to view at least one image 202. As shown in FIG. 2 , the image 202 can be viewed while a treatment is in progress or after a treatment is completed. For example, the clinician device 130 displays the image 202 during an ongoing treatment, with new images 202 periodically received. The software application 202 can compile each new image 202 into a screen progression video 146, which builds a video as the images 202 are received and the treatment continues. In addition, the clinician device 132 displays the image 202 as the created screen progression video 146 after the treatment is completed. It should be understood that since an image of the screen 112 of the automated dialysis machine 106 is captured, any overlay screens are also captured in the same image 202.

[0130] 8 is a flow diagram of an example procedure 800 for providing a remote view replay of a treatment session using images, according to an example embodiment of the present disclosure. Although procedure 800 is described with reference to the flow diagram shown in FIG. 8 , it should be understood that many other ways of performing the steps associated with procedure 800 may be used. For example, the order of many of the blocks may be changed, some blocks may be combined with other blocks, and many of the described blocks may be optional. For example, a clinician may instead choose to view current settings or treatments rather than replay an already completed procedure. The operations described in procedure 800 may be specified by one or more instructions and may be performed across multiple devices, including, for example, server 108 and / or clinician device 130.

[0131] The exemplary procedure 800 is initiated by the software application 144, which allows the clinician to search and / or filter indexed records managed by the server 108 to identify a desired dialysis treatment / setting (block 802). The software application 144 may allow the clinician to search / filter by patient identifier, medical device identifier, treatment session information (e.g., date, duration, time, etc.), etc. The software application then allows the clinician to select a treatment session, which causes a request message 803 to be sent to the server 108 (block 804). In some embodiments, the server 108 is configured to arrange and compile images 202 associated with the selected treatment session into a screen progression video 146. Because each image 202 is associated with a timestamp, the server 108 is configured to order or arrange the images 202 in chronological order. The server 108 then sends the screen progression video 146 to the software application 144 (block 806).

[0132] In some examples, the software application 144 instead creates the screen progression video 146. In these examples, the server 108 sends the images 202. The software application 144 then arranges the images 202 by timestamp to create a video sequence. The software application 144 then compiles the screen progression video 146 (block 808).

[0133] In some embodiments, the server 108 and / or software application 144 is configured to reduce the size of the screen progression video 146 by adding only images 202 that are different from the previous screen. The server 108 and / or software application 144 may use a pixel comparison operation to identify the differences. Alternatively, the automated dialysis machine 106 creates images 202 only when the medical data 120 changes, so that the server 108 and / or software application 144 does not have to search for and omit duplicate images 202.

[0134] 8 , after the screen advance video 146 is compiled, the software application 144 displays the screen advance video 146 (block 810). The software application 144 may then receive one or more inputs 809 for playback controls (block 812). The inputs 809 may include controls for play, slow play, rewind, fast forward, stop, or fast forward to an alarm or event (stored in association with the images 202). The software application 144 adjusts the screen advance video 146 accordingly based on the received playback controls (block 814). The exemplary procedure 800 continues until the clinician terminates the playback of the screen advance video 146.

[0135] In some embodiments, access to the images 202 and / or the screen progression video 146 may be secured using a VNC framework. FIG. 9 is a diagram of a medical system 900 using VNC for remote screen viewing of medical devices, according to an exemplary embodiment of the present disclosure. In the illustrated example, in event 1, a service technician or on-site specialist enables the remote view feature on the automated dialysis machine 106. In event 2, the service technician or on-site specialist sets VNC parameters to allow the automated dialysis machine to connect to the server 108 (e.g., the VNC server in this embodiment). Next, in event 3, the clinician must select the “Remote View” button on the automated dialysis machine 106. Selecting the “Remote View” button causes the automated dialysis machine 106 to record and transmit an image 202 of the screen 112. Thus, this embodiment provides a remote view of the automated dialysis machine 106 only if the option is selected on the machine itself.

[0136] Also, in Event 3, the automated dialysis machine 106 is configured to display a network address (e.g., IP address) and a password. In Event 4, the automated dialysis machine 106 sends a message to the server 108 indicating that the "Remote View" function has been selected. The message may include the password. The message causes the server 108 to initiate a VNC session for the automated dialysis machine 106. The server 108 uses the password to access the VNC session. At this point (Event 6), the automated dialysis machine 106 begins sending images 202 of the screen 112 to the server 108, which stores the images 202 in the memory device 109 in a data structure or file indexed to the VNC session, the patient, and / or the automated dialysis machine 106. The automated dialysis machine 106 may generate images of the screen 112, for example, every 1 to 3 seconds. Additionally or alternatively, the automated dialysis machine 106 can record images of the screen 112 when at least a portion of the medical data changes and / or when a different screen is displayed by the display device 110.

[0137] In some embodiments, the automated dialysis machine 106 generates the image 202 on the screen 112 and then compresses the image for transmission to the digital communication module 902, which is the network interface for the automated dialysis machine 106. The digital communication module may then decompress the image as a frame buffer and then transmit the image to the server 108. In other examples, the image 202 is not compressed by the automated dialysis machine 106, or a compressed image 202 is transmitted from the digital communication module 902 to the server 108.

[0138] At event 5, the software application 144 prompts the clinician for a network address and password. The software application 144 transmits the received network address and password to the server 108, which verifies that the network address and password match the session password and network address of the automated dialysis machine 106. At this point, the software application 144 is authenticated by the server 108 to view images 202 from the automated dialysis machine 108. The software application 144 receives the images 202 associated with the VNC session from the server 108. The software application 144 then displays the images 202. In some embodiments, the software application 144 or the server 108 arranges the images 202 in chronological order based on their corresponding timestamps, allowing the images 202 to be shown as a screen-advancing video 146. III. Medical Device Data and Image Processing Embodiments

[0139] As described above, a remote view of the medical device screen may be displayed within a software application on the clinician device by transmitting medical data and a screen identifier or an image of the medical device screen. Figure 10 is a diagram of a medical device (e.g., an automated dialysis machine 106) according to an exemplary embodiment of the present disclosure. As shown in Figure 10, a control processor 118a is communicatively connected to the display device 110. The control processor 118a is also communicatively connected to a safety processor 118b via an FPGA bus. The safety processor 118b is configured to provide fail-safe operation for the automated dialysis machine 118a if the control processor 118a is not operational. The safety processor 118b may also handle startup and shutdown operations.

[0140] The control processor 118a is also communicatively connected to a digital communications module 902 via a serial or USB connection. The digital communications module 902 includes a transceiver, a microprocessor, RAM, and flash memory to enable communication with a network. In some embodiments, the digital communications module 902 is included within the automated dialysis machine 106. In other embodiments, the digital communications module 902 is external and communicatively connected to the automated dialysis machine 106.

[0141] The automated dialysis machine 106 also includes, in some examples, a pump, a scale, a pressure sensor, a pressure solenoid, an air bubble sensor, a clamp, a syringe pump, and a blood leak sensor, which are connected to the control processor 118a via a CP FPGA. The pump, the scale, the pressure sensor, the pressure solenoid, the air bubble sensor, the clamp, the syringe pump, and the blood leak sensor generate the medical data 120 described above. As shown in FIG. 10 , the control processor 118a creates the medical data 120 based on the operation of the pump, the scale, the pressure sensor, the pressure solenoid, the air bubble sensor, the clamp, the syringe pump, and the blood leak sensor. The control processor 118a then incorporates the medical data 120 into one or more screens 112 displayed by the display device 110 via LVDS. Furthermore, in accordance with some embodiments, the control processor 118a transmits the medical data 120 (and any newly modified / generated medical data) to the server 108.

[0142] FIG. 11 is a diagram of a control processor 118a for processing a display device screen for an automated dialysis machine, according to an exemplary embodiment of the present disclosure. The control processor 118a includes a kernel 1102 having a frame buffer 1104, which is a pixel buffer. The frame buffer 1104 is a contiguous memory area located within the address space of the control processor's 118a CPU. The frame buffer 1104 contains the current screen 112 shown on the display device 110. The contents of the frame buffer 1104 are prepared by the control processor's 118a graphics engine using software rendering or a graphics accelerator. For example, the software rendering or graphics accelerator is used to incorporate specified medical data 120 into the screen for display. The software rendering or graphics accelerator can use data values ​​to change the appearance of some graphics and how those graphics are rendered. The kernel 1102 provides an option to read the frame buffer 1104 so that a display application can retrieve the frame buffer as needed for display on the display device 110.

[0143] To record an image 202 of the screen 112, a screen capture application 1106 running on the control processor 118a periodically (e.g., every second) reads the frame buffer 110. The screen capture application 1106 then copies the contents of the frame buffer 1104 to an application buffer, which is processed by a JPEG conversion application 1108 into a compressed JPEG image 202. The control processor 118a then sends the compressed JPEG image 202 over a serial connection to the digital communication module 902, which decompresses the image 202. IV. Camera Verification Embodiments

[0144] In some embodiments, the accuracy of the graphical representation of the screen of a medical device may be verified. This verification allows a clinician to confirm that the currently displayed screen is correct. Figure 12 is a diagram of a medical system 1200 having a camera 1202 for providing verification of a remote screen view, according to an exemplary embodiment of the present disclosure. The camera 1202 is configured to record video or images 1204 that are transmitted to the server 108. The camera 1202 is positioned facing the display device 110 of the medical device (e.g., an automated dialysis machine 106) to record an image of the screen 112.

[0145] The server 108 is configured to analyze the video or image 1204 to segment the screen 112. As described above, the medical device 106 also transmits the image 202 of the screen 112. The server 108 then compares the video or image 1204 from the camera 1202 with the image 202 from the frame buffer 1104 of the medical device 106. If there is a match, the server 108 can provide an indication that the image 202 is correct. If there is no match, the server 108 can send an indicator to the software application 144 that the image 202 is not the current or most recent screen view of the medical device 106. The indicator can include an audible and / or visual indicator. In some embodiments, the server 108 may not perform the comparison, and the software application 144 instead displays the video or image 1204 from the camera 1202 along with the image 202 to allow the clinician to make the comparison. In yet other embodiments, the software application 144 performs the comparison.

[0146] The server 108 and / or software application 144 may perform the comparison using pixel analysis. For example, the server 108 and / or software application 144 may compare pixel color values ​​of the video or image 1204 from the camera 1202 with pixel color values ​​of the image 202. A good comparison occurs when pixels have approximately the same values ​​in the same locations. In other embodiments, the server 108 and / or software application 144 may perform optical character recognition to identify text in the images 1204 and 202. The server 108 and / or software application 144 then compares the identified text to determine if there is a match.

[0147] In some embodiments, a comparison may be made between video or images 1204 from the camera 1202 and medical data 120 entered into the user interface 136. The system 1200 operates in the same manner as described above, but instead of comparing images, medical data and a corresponding user interface are used for comparison. For example, the server 108 and / or software application 144 may run an OCR routine on the video or images 1204 from the camera 1202 to identify the medical data 120. The server 108 and / or software application 144 also receives images 202 or medical data 120 from the medical device 106. Once the images 202 are received, the server 108 and / or software application 144 run an OCR routine to identify the medical data and compare it to the identified medical data from the camera images 1204. Once the medical data 120 is received, the data itself is compared to the medical data from the camera images 1204. The comparison may be performed periodically (e.g., every minute, every 2 minutes, every 5 minutes, every 15 minutes, etc.), or when updated medical data is detected or when a new image 202 or 1202 is received.

[0148] The output from the camera 1202 may be associated with the medical device 106 at the server 108. In other embodiments, the camera 1202 may be directly connected to the clinician device 130 to allow the software application 144 to perform the comparison. In these examples, the images 1204 are not transmitted to the server 108, but instead are transmitted from the camera 1202 to the software application 144, for example, via a wired or wireless connection.

[0149] In some embodiments, the medical device 106 can display a barcode or other code on the screen 112. The medical device 106 can update the barcode periodically, for example, every 1 to 30 seconds. In these embodiments, the server 108 and / or software application 144 is configured to compare the barcodes in the images 1204 and 202 to determine a good comparison. The comparison can be performed using pixel analysis. Thus, the use of the camera 1202 ensures that the remote screen view is accurate to the clinician.

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

Claims

1. 1. A system for remotely viewing medical data displayed on a screen of a medical device, comprising:

1. A medical device for performing a medical procedure for a patient, the medical device including a plurality of different screens that can be shown on a display device, each screen being assigned an identifier and configured to show a subset of medical data associated with the medical procedure, the medical device comprising: an identifier of a screen to be displayed by the display device of the medical device; medical data displayed on the screen; the medical device configured to transmit a user device including a processor and a memory, the memory storing instructions that, when executed by the processor, cause the processor to operate a software application, the software application including a plurality of non-entered user interfaces corresponding to the plurality of different screens of the medical device, each user interface including at least one data field corresponding to the subset of medical data associated with the associated screen; a server communicatively connected to the medical device and the user device via a network, the server comprising: receiving the identifier of the screen displayed by the medical device and the medical data shown on the screen; After receiving a request message from the software application of the user device, sending the identifier of the screen displayed by the medical device and the medical data shown in the screen to the software application; Selecting an uninputted user interface corresponding to the identifier on the screen; The system causes the received medical data to be entered into the at least one data field of the selected user interface.

2. the medical device is further configured to transmit a timestamp along with the identifier of the screen and the medical data shown on the screen; 10. The system of claim 1, wherein the server is further configured to store the timestamp in a medical record associated with the patient in association with the identifier of the screen displayed by the medical device and the medical data shown on the screen.

3. the server receives a second timestamp that is subsequent to the first timestamp; (i) a second identifier of a second screen displayed by the display device of the medical device and second medical data shown on the second screen; or (ii) the identifier of the screen displayed by the display device of the medical device and updated medical data shown on the screen; and and further storing said at least one of (i) or (ii) in said medical record associated with said patient. The system of claim 2 further configured to:

4. The software application For (i), selecting a second uninputted user interface corresponding to the second identifier on the screen; inputting the received second medical data into the at least one data field of the selected second user interface; Creating a screen progression video using the user interface associated with the timestamp and the second user interface associated with the second timestamp. The system of claim 3 further configured to:

5. The software application For (ii), updating the at least one data field of the selected user interface with the received updated medical data; Creating a screen progression video using the user interface associated with the timestamp and the user interface associated with the second timestamp. The system of claim 3 further configured to:

6. 6. The system of claim 4 or 5, wherein the software application includes options to play the screen progression video, fast forward the screen progression video, rewind the screen progression video, slow down the playback speed of the screen progression video, or skip to the next alarm or event provided in the screen progression video.

7. The system of claim 1 , wherein the software application is further configured to send the request message to the server after the medical procedure is completed.

8. the medical data includes a data label; 10. The system of claim 1, wherein the software application is configured to enter the received medical data into the at least one data field of the selected user interface by matching the data label of the medical data with the at least one data field of the selected user interface.

9. the server is configured to store the identifier of the screen displayed by the medical device and the medical data shown on the screen in a medical record associated with the patient, the medical record including an identifier of the patient, an identifier of the medical device, and medical procedure session information; 2. The system of claim 1, wherein the request message includes at least one of the identifier of the patient, the identifier of the medical device, or the medical procedure session information, and the request message causes the server to select the identifier of the screen displayed by the medical device and the medical data shown in the screen for transmission to the software application.

10. 10. The system of claim 1, wherein the medical device comprises at least one of a hemodialysis machine, a hemodiafiltration machine, a large volume infusion pump, a syringe pump, a patient-controlled analgesia pump, a parenteral nutrition pump, a peritoneal dialysis machine, a continuous renal replacement therapy (CRRT) machine, a ventilator, a physiological monitor / sensor, or a patient bedside monitor.

11. The system of claim 1 , wherein the server is a cloud-based server or is located within a medical facility.

12. 2. The system of claim 1, wherein the medical data includes at least one of ultrafiltration (UF) volume, treatment time, concentrate type, sodium concentration, bicarbonate concentration, heparin bolus volume, heparin flow rate, heparin stop time, heart rate, dialysis fluid temperature, dialysis fluid flow rate, dialysis fluid conductivity, UF profiling data, sodium profiling data, bicarbonate profiling data, blood flow rate to dialyzer, pre-infusion and post-infusion volumes, and an indication of whether UF is isolated, an indication of whether a single needle is used for arterial and venous connections, an event, an alarm, or diagnostic information.

13. The system of claim 1 , wherein at least one of the non-input user interfaces is an overlay user interface displayed over another user interface.

14. The medical device comprises: receiving physiological data from at least one sensor; Including the physiological data along with the medical data The system of claim 1 configured to:

15. The server receiving physiological data from at least one sensor; Including the physiological data along with the medical data The system of claim 1 configured to:

16. A system for remotely viewing medical data displayed on a screen of a medical device, a user device including a processor and a memory, the memory storing instructions that, when executed by the processor, cause the processor to operate a software application, the software application including a plurality of blank user interfaces corresponding to a plurality of different screens of a medical device, each user interface including at least one data field corresponding to a subset of medical data associated with the associated screen; a server communicatively connected to the medical device and the user device via a network, the server comprising: receiving from the medical device identifiers of screens displayed by the medical device, the medical data shown on each screen in connection with a medical procedure for a patient, and a timestamp when the medical data was displayed, generated, or transmitted; after receiving a request message from the software application of the user device, sending the identifier of the screen, the corresponding medical data, and the associated timestamp to the software application; Selecting an uninputted user interface corresponding to the identifier on the screen; Entering the received medical data into the at least one data field of the selected user interface; Sequencing the user interfaces based on the timestamps; The system causes the user interface to be presented in a video-like sequential order to replay the medical procedure.

17. 17. The system of claim 16, wherein the software application is configured to send the request message to the server after the medical procedure is completed.

18. the server is configured to store the identifier of the screen, the medical data, and the corresponding timestamp in a medical record including at least one of an identifier of the patient, an identifier of the medical device, and medical procedure session information; 17. The system of claim 16, wherein the request message includes at least one of the identifier of the patient, the identifier of the medical device, or the medical procedure session information, and the request message causes the server to select the identifier of the screen, the medical data, and the corresponding timestamp for transmission to the software application.

19. 1. A system for remotely viewing a screen of a medical device, comprising:

1. A medical device for performing a medical procedure for a patient, said medical device comprising: a display device configured to display a medical procedure screen including the medical data; a processor configured to record an image of the medical procedure screen and compress the image; a digital communication module configured to receive the compressed image, decompress the image, and transmit the image to a server for storage in a memory device; a user device including a processor and a memory, the memory storing instructions that, when executed by the processor, cause the processor to operate a software application; a server communicatively connected to the medical device and the user device via a network, the server comprising: receiving the image from the digital communication module; The system transmits the image after receiving a request message from the software application of the user device and causes the software application to display the image.

20. 20. The system of claim 19, wherein the processor of the medical device is configured to receive a remote view input and record the image of the medical procedure screen after receiving the remote view input.

21. The processor: After the remote view input is received, displaying at least one of an IP address or a password; configured to transmit the at least one of the IP address or the password to the server for evaluating the image; 20. The system of claim 19, wherein the software application is configured to prompt for the at least one of the IP address or the password to access the images associated with the medical device.

22. The system of claim 17 , wherein the processor of the medical device is configured to associate a timestamp with the recorded image.

23. 23. The system of claim 22, wherein the processor associates the timestamp with the recorded image by at least one of storing the timestamp as metadata for the image, displaying a watermark of the timestamp on the image, or storing the timestamp together with the image in memory of the medical device.

24. the processor is further configured to record a next image of the medical procedure screen every 1 second to every 30 seconds, associate a respective timestamp with the next image, and compress the next image; the digital communication module is configured to decompress the next image and transmit the next image to the server; 23. The system of claim 22, wherein the server sends the next images to the software application, causes the software application to order the next images based on their respective timestamps, and displays the ordered next images.

25. the processor is further configured to record a next image of the medical procedure screen when a new medical procedure screen is displayed or when at least a portion of the medical data changes, associate a respective timestamp with the next image, and compress the next image; the digital communication module is configured to decompress the next image and transmit the next image to the server; 23. The system of claim 22, wherein the server sends the next images to the software application, causes the software application to order the next images based on their respective timestamps, and displays the ordered next images.

26. 20. The system of claim 19, wherein the server is a Virtual Network Computing (VNC) server and the software application is a VNC viewer application.

27. recording a camera image of the medical procedure screen; Sending the camera image to the server and a camera configured to:

20. The system of claim 19, wherein the server is configured to transmit the camera image to the software application, causing the software application to display the camera image along with the image of the medical procedure screen created by the medical device.

28. At least one of the server or the software application: comparing the camera image to the image of the medical procedure screen generated by the medical device; If the camera image does not match the image of the medical procedure screen created by the medical device, providing an audible and / or visual indication that the image of the medical procedure screen created by the medical device is incorrect.

28. The system of claim 27, configured to:

29. 30. The system of claim 28, wherein at least one of the server or the software application is configured to perform the comparison using optical character recognition or pixel analysis.

30. the medical device is configured to show a barcode on the medical procedure screen, and the camera image is configured to include the barcode; 30. The system of claim 28, wherein the at least one of the server or the software application is configured to perform the comparison by comparing the barcode in the image recorded by the medical device with the barcode contained in the camera image.

31. 31. The system of claim 30, wherein the medical device is configured to periodically update the barcode.

Images