Digital communication module for a self-contained medical device communication platform

Abstract

Disclosed herein is a digital communication module for a self-contained medical device communication platform. In one example, the digital communication module is communicatively coupled to a therapy module of a medical device to relay medical device data to an electronic medical record ("EMR") server connected to a medical network. The digital communication module is connected to at least one other digital communication module via a wireless proprietary network separate from the medical network. The digital communication module determines that medical device data from the medical device should be transmitted over the wireless proprietary network to one of the other digital communication modules connected to the EMR server via the medical network. The other of the digital communication modules receives the medical device data and then routes the medical device data to the EMR server via the medical network.

Description

[Background technology]

[0001] A medical network for a healthcare facility typically connects a significant number of medical devices. Known medical networks generally include a local area network ("LAN") and / or a wireless LAN ("WLAN"), such as a Wi-Fi or Ethernet connection. In such networks, connected medical devices transmit medical procedure data and / or medical event data (e.g., alarms or alerts) to a centralized gateway or server. The centralized server or gateway then stores the medical procedure data and / or medical event data in the appropriate patient electronic medical record ("EMR"). The centralized server may also transmit the medical procedure data and / or medical event data to a clinician computer for monitoring. If permitted, the centralized server may route prescriptions and / or medical device programming instructions to the appropriate medical device.

[0002] In the above-described medical networks, medical devices are configured only with the destination network address of a centralized server or gateway. Therefore, communication is limited to the connection between the medical device and the centralized server or gateway. As described above, the server or gateway determines how medical procedure data and / or medical event data should be routed on the medical network. Known medical networks leave medical devices at the edge or endpoint of the network, which limits or inhibits the interconnectivity of medical devices.

[0003] Another known challenge with medical networks is that their overall operability is limited to the network configuration specified by the healthcare facility. Because medical networks in healthcare facilities are designed for security and reliability, enhanced functionality or device interconnectivity is typically not considered or deployed in known medical networks. In one example, a medical device may include enhanced network operability, such as the ability to communicate with other medical devices or sensors. However, such functionality is only operational if the medical network is configured to enable device-to-device communication. In many cases, healthcare facilities do not modify or upgrade their networks to support such functionality due to the cost, effort, and potential risks. Adapting a network to support specific functionality for dozens to hundreds of different medical devices is cumbersome, and there is a risk that one function or medical device will disrupt the entire network. As a result of the limited functionality provided by the medical network, some medical device functionality is never used or even designed or implemented.

[0004] Therefore, there is a need for a medical system that does not restrict the functionality or operation of medical devices. There is also a need for a medical system that allows for medical device interconnectivity. Summary of the Invention

[0005] Disclosed herein are exemplary systems, methods, and apparatus for creating a self-contained network implemented between medical devices. The medical devices disclosed herein include or are connected to a digital communications module ("DCM"). The digital communications module may also be referred to as a digital communications device. An exemplary DCM is disposed between the processor (or therapy module) of the medical device and the medical network. In some embodiments, the DCM is external to the medical device (connected via a serial or Ethernet connection). In other embodiments, the DCM is included within or integrated with the medical device.

[0006] According to a first independent aspect, there is provided a healthcare system comprising: at least one medical device (104), one or more sensors and one or more actuators; Memory and a processor (107) configured to receive data from the one or more sensors and to control the one or more actuators to perform a medical task, a processor (107) that can access the memory and is configured to store data including medical device data (303); a communication unit connected to the processor (107), the communication unit including at least one of a serial input port, an Ethernet input port, and a wireless input port; At least one medical device (104) comprising: at least one digital communication module (102) associated with said medical device (104), said digital communication module (102) comprising: an input interface (304) communicatively coupled to the communication unit of the medical device (104), the input interface (304) including at least one of a serial input port, an Ethernet input port, and a wireless input port; an output interface (306) configured for communicative coupling with (i) an electronic medical record server (108) via a medical network (106) and (ii) at least one other digital communication module (102A) via a wireless proprietary network (400), said output interface (306) including at least one of a serial output port, an Ethernet output port, and a wireless output port; a file configuration manager (330) configured to store at least one configuration file (332) together with an identifier of the digital communication module (102); a data manager (302) communicatively coupled to the input interface (304), the output interface (306), and the file structure manager (330), the data manager (302) comprising: After being powered on, sending an awake message to the at least one other digital communication module (102A) via the wireless proprietary network (400), the awake message including the identifier of the digital communication module (102) and a date / time of the power-on; receiving a response message from each of the at least one other digital communication module (102A) via the wireless proprietary network (400), the response message including an identifier or network address of the respective other digital communication module (102A) and a date / time indication of when the respective other digital communication module (102A) was powered on; receiving medical device data (303) from the medical device (104); determining that the medical device data (303) should be transmitted to the EMR server (108) via a first one of the other digital communication modules (102A) having an earliest date / time indication; transmitting the medical device data (303) to the first digital communication module (102) for transmission to the EMR server (108); a data manager (302) configured to: and at least one digital communication module (102) comprising:

[0007] In a second independent aspect, 1. A healthcare system comprising: at least one medical device (104), one or more sensors and one or more actuators; Memory and a processor (107) configured to receive data from the one or more sensors and to control the one or more actuators to perform a medical task, a processor (107) that can access the memory and is configured to store data including medical device data (303); a communication unit connected to the processor (107), the communication unit including at least one of a serial input port, an Ethernet input port, and a wireless input port; At least one medical device (104) comprising: at least one digital communication module (102) associated with said medical device (104), said digital communication module (102) comprising: an input interface (304) communicatively coupled to the communication unit of the medical device (104), the input interface (304) including at least one of a serial input port, an Ethernet input port, and a wireless input port; an output interface (306) configured for communicative coupling with (i) at least one other digital communication module (102A) via a wireless proprietary network (400), and (ii) a clinician device via the wireless proprietary network (400) or a direct wireless link, the output interface (306) including at least one of an Ethernet output port and a wireless output port; a file configuration manager (330) configured to store at least one configuration file (332) with network addresses or identifiers of clinician devices and criteria for sending notifications to the clinician devices; a data manager (302) communicatively coupled to the input interface (304), the output interface (306), and the file structure manager (330), the data manager (302) comprising: receiving medical device data (303) from said medical device (104); determining that at least a portion of said medical device data (303) meets said criteria; sending a notification message to the clinician device (322) via the proprietary network (400) or the direct wireless link, the notification message indicating the at least a portion of the medical device data (303) that meets the criteria; a data manager (302) configured to: and at least one digital communication module (102) comprising:

[0008] In a further independent aspect, a process for transferring medical device data (303) from at least one medical device (104) to an EMR server (108) through at least one digital communication module (102), comprising: The medical device (104) comprises: one or more sensors and one or more actuators; Memory and a processor (107) configured to receive data from the one or more sensors and to control the one or more actuators to perform a medical task, a processor (107) that can access the memory and is configured to store data including medical device data (303); a communication unit connected to the processor (107), the communication unit including at least one of a serial input port, an Ethernet input port, and a wireless input port; The digital communication module (102) an input interface (304) communicatively coupled to the communication unit of the medical device (104), the input interface (304) including at least one of a serial input port, an Ethernet input port, and a wireless input port; an output interface (306) configured for communicative coupling with (i) an electronic medical record server (108) via a medical network (106) and (ii) at least one other digital communication module (102A) via a wireless proprietary network (400), said output interface (306) including at least one of a serial output port, an Ethernet output port, and a wireless output port; a file configuration manager (330) configured to store at least one configuration file (332) together with an identifier of the digital communication module (102); a data manager (302) communicatively coupled to the input interface (304), the output interface (306), and the file structure manager (330); The process comprises: coupling the digital communication module (102) to the medical device (104); coupling the digital communication module (102) to the EMR server (108); After being powered on, sending an awake message via the data manager (302) to the at least one other digital communication module (102A) over the wireless proprietary network (400), the awake message including the identifier of the digital communication module (102) and a date / time of the power-on; receiving a response message from each of the at least one other digital communication module (102A) via the wireless proprietary network (400), the response message including an identifier or network address of the respective other digital communication module (102A) and a date / time indication of when the respective other digital communication module (102A) was powered on; receiving medical device data (303) from the medical device (104); determining that the medical device data (303) should be transmitted to the EMR server (108) via a first one of the other digital communication modules (102A) having an earliest date / time indication; transmitting the medical device data (303) to the first digital communication module (102) for transmission to the EMR server (108); a data manager (302) configured to: A process is provided, comprising:

[0009] Further details of the system and process are provided in the following paragraphs. While the following aspects are directed to the system and the communication module (itself or part of the system), the process steps performed by the processor of the medical device and by the data manager of the digital communication module may also be part of the above-described process for transferring medical device data.

[0010] In a third aspect relating to any one of the preceding aspects, the medical system comprises a plurality of medical devices (104) and a plurality of digital communication modules (102A-0, ..., 102A-6), each of the plurality of medical devices (104) being associated with an individual digital communication module (102) of the plurality of digital communication modules (102A-0, ..., 102A-6).

[0011] In a fourth aspect of the preceding aspect, the plurality of medical devices (104) includes medical devices of various natures selected from the group including one or more apparatuses for the treatment of renal disease, one or more infusion pumps, one or more nutrient solution delivery devices, one or more plasmapheresis machines, and one or more purified water for medical preparation machines.

[0012] In a fifth aspect relating to either of the preceding two aspects, the digital communication module (102) is configured as a gateway that enables the digital communication modules (102A-0, ..., 102A-6) in a mesh network to communicate with each other separately from a medical network (106) associated with a healthcare facility.

[0013] In a sixth aspect relating to any one of the preceding three aspects, the plurality of digital communication modules (102A-0, ..., 102A-6) are configured to designate one digital communication module (102) as a node gateway that connects (optionally exclusively) with the medical network (106), and in particular, each of the plurality of digital communication modules (102A-0, ..., 102A-6) transmits individual medical device data (303) to the node gateway digital communication module, which routes the received medical device data (303) to the medical network (108), and optionally the node gateway digital communication module communicates with the medical network (106) at regular intervals.

[0014] In a seventh aspect relating to any one of the preceding four aspects, the plurality of digital communication modules (102A-0, ..., 102A-6) are configured to communicate with each other to create a self-contained proprietary wireless network (400) hosted by the plurality of digital communication modules, e.g., an IoT gateway, associated with the plurality of medical devices (104).

[0015] In an eighth aspect related to the preceding aspect, the self-contained proprietary wireless network (400) is configured to transmit medical device data (303) between digital communication modules (102A-0, .., 102A-6) for single-point transmission to the medical network (106).

[0016] In a further eighth aspect, the self-contained proprietary wireless network (400) is configured to share the same medical device data (303) among the digital communication modules (102A-0, ..., 102A-6) connected to the self-contained proprietary wireless network (400).

[0017] In a ninth aspect according to any one of the preceding aspects, the medical device (104) is a medical fluid delivery machine and the one or more actuators include one or more pumps.

[0018] In a tenth aspect related to any one of the preceding aspects, the medical device (104) is an apparatus for treating renal disease, such as a continuous renal replacement therapy (CRRT) machine, a hemodialysis machine, or a peritoneal dialysis machine, including a disposable line set, and the one or more actuators include one or more pumps.

[0019] In an eleventh aspect according to any one of the preceding aspects, the medical device (104) comprises: a filtration unit having a primary chamber and a secondary chamber separated by a semipermeable membrane; a blood circuit, a blood removal line extending between a first end connected to the inlet of the primary chamber and a second end for connection to a patient; a blood return line extending between a first end connected to the outlet of the primary chamber and a second end for connection to the patient; a blood circuit including: a blood pump for circulating blood through said blood circuit; a dialysate line connected to the outlet of said secondary chamber; optionally, one or more lines for transferring individual solutions into the blood; A device for the treatment of renal disease involving extracorporeal circulation of blood, comprising:

[0020] In a twelfth aspect related to any one of the preceding aspects, the medical device data (303) includes both medical procedure data and medical event data, such as alarms or alerts.

[0021] In a thirteenth aspect according to any one of the preceding aspects, the system further comprises a medical network (106) and an electronic medical record (EMR) server (108).

[0022] In a fourteenth aspect relating to any one of the preceding aspects, the digital communication module (102) is external to the case of the medical device (104) and is physically connected to the medical device (104) via a serial or Ethernet connection, or alternatively, is connected via a wireless connection.

[0023] In a fifteenth aspect relating to any one of the preceding aspects 1 to 13, the digital communication module (102) is included within a case of the medical device (104) or is integrated with the medical device (104).

[0024] In a sixteenth aspect relating to any one of the preceding aspects, the system further comprises a medical network and an electronic medical record (EMR) server (108), the medical network (106) including at least one of a Wi-Fi network or an Ethernet network, and the digital communication module (102) transmits the medical device data (303) to the medical network for inclusion in the EMR server (108).

[0025] In a seventeenth aspect related to the preceding aspects, the medical network (106) includes at least one of a local area network "LAN," a wireless local area network "WLAN," an Ethernet network, a Wi-Fi network, and one or more communication elements in a group of network equipment such as gateways, routers, system hubs, switches, and the like for establishing communication connections and routing data, and in particular, the medical network (106) includes one or more firewalls that restrict access to only authorized remote devices.

[0026] In an eighteenth aspect according to any one of the preceding aspects when dependent on aspect seven, the proprietary wireless communication network (400) is separate from a medical network.

[0027] In another aspect of any one of the preceding aspects, the medical system includes the clinician device (322) connected to the digital communication module (102) through the proprietary network (400) or the direct wireless link, and the clinician device (322) does not require connection to the medical network (106) to receive the notification message, and in particular, the clinician device (322) is not connected to the medical network (106).

[0028] In a nineteenth independent aspect, a digital communication module (102) includes: an input interface (304) communicatively coupled to the communication unit of the medical device (104), the input interface (304) including at least one of a serial input port, an Ethernet input port, and a wireless input port; an output interface (306) configured for communicative coupling with (i) an electronic medical record server (108) via a medical network (106) and (ii) at least one other digital communication module (102A) via a wireless proprietary network (400), said output interface (306) including at least one of a serial output port, an Ethernet output port, and a wireless output port; a file configuration manager (330) configured to store at least one configuration file (332) along with an identifier of the digital communication module (102); a data manager (302) communicatively coupled to the input interface (304), the output interface (306) and the file structure manager (330), the data manager (302) comprising: After being powered on, sending an awake message to the at least one other digital communication module (102A) via the wireless proprietary network (400), the awake message including the identifier of the digital communication module (102) and a date / time of the power-on; receiving a response message from each of the at least one other digital communication module (102A) via the wireless proprietary network (400), the response message including an identifier or network address of the respective other digital communication module (102A) and a date / time indication of when the respective other digital communication module (102A) was powered on; receiving medical device data (303) from the medical device (104); determining that the medical device data (303) should be transmitted to the EMR server (108) via a first one of the other digital communication modules (102A) having an earliest date / time indication; transmitting the medical device data (303) to the first digital communication module (102) for transmission to the EMR server (108); a data manager (302) configured to: A digital communication module (102) is provided, comprising:

[0029] In a twentieth independent aspect, a digital communication module (102) comprising: an input interface (304) communicatively coupled to the communication unit of the medical device (104), the input interface (304) including at least one of a serial input port, an Ethernet input port, and a wireless input port; an output interface (306) configured for communicative coupling with (i) at least one other digital communication module (102A) via a wireless proprietary network (400), and (ii) a clinician device via the wireless proprietary network (400) or a direct wireless link, the output interface (306) including at least one of an Ethernet output port and a wireless output port; a file configuration manager (330) configured to store at least one configuration file (332) with a network address or identifier of a clinician device and criteria for sending notifications to the clinician device; a data manager (302) communicatively coupled to the input interface (304), the output interface (306) and the file structure manager (330), the data manager (302) comprising: receiving medical device data (303) from the medical device (104); determining that at least a portion of the medical device data (303) meets the criteria; sending a notification message to the clinician device via the proprietary network (400) or the direct wireless link, the notification message indicating the at least a portion of the medical device data (303) that meets the criteria; a data manager (302) configured to: A digital communication module (102) is provided, comprising:

[0030] The nineteenth and twentieth independent aspects may be combined with any of the preceding aspects 1-18 and with the following aspects.

[0031] In a twenty-first aspect related to the preceding aspect, the wireless proprietary network (400) includes at least one of a Zigbee® wireless protocol, a Z-Wave® wireless protocol, a WeMo® wireless protocol, and a low-power wide area network ("LPWAN") wireless protocol; The direct wireless link is provided using at least one of a Bluetooth® wireless protocol, a Bluetooth® mesh wireless protocol, and a Bluetooth® 5.0 wireless protocol.

[0032] In a twenty-second aspect related to either one of the preceding two aspects, the direct wireless link is included as part of the wireless proprietary network (400).

[0033] In a twenty-third aspect related to any one of the preceding three aspects, the criteria for the notification correspond to at least one of an alarm, an alert, and an event.

[0034] In a 24th aspect according to any one of the preceding four aspects, the data manager (302) allowing authorized connections from the clinician device (322); providing a template form requesting data regarding which notifications are desired and including configured thresholds and / or conditions regarding when said notifications should be generated, in particular said template form requesting a priority for said alarm, event, or alert; using template form data to establish said criteria; The device is further configured to:

[0035] In a 25th aspect relating to any one of the preceding five aspects, the data manager (302) is configured to broadcast and rebroadcast the notification message to ensure that the message reaches the clinician device (322), and the data manager (302) is configured to rebroadcast the notification message until one of the following is met: a maximum broadcast time is reached, a maximum number of broadcasts has been made, or an acknowledgment message when the notification message is received from the clinician device (322).

[0036] In a 26th aspect according to any one of the preceding aspects, the data manager (302) receiving a power-off message from the first digital communication module (102) indicating that the first digital communication module (102) is no longer available; removing the date / time indication of the first digital communication module (102); receiving second medical device data (303) from the medical device (104); determining that the second medical device data (303) should be transmitted to the EMR server via a second one of the other digital communication modules (102A) having an earliest date / time indication after removing the date / time indication of the first digital communication module (102); transmitting the second medical device data (303) to the second digital communication module (102) for transmission to the EMR server (108); The device is further configured to:

[0037] In a 27th aspect according to any one of the preceding aspects, the data manager (302) receiving a power-off message from the first digital communication module (102) indicating that the first digital communication module (102) is no longer available; removing the date / time indication of the first digital communication module (102); receiving second medical device data (303) from the medical device (104); determining that the second medical device data (303) should be transmitted to the EMR server (108) via the digital communication module (102) based on the digital communication module (102) having the earliest date / time indication among the other digital communication modules (102A); transmitting the second medical device data (303) to the EMR server (108) via the communication coupling of the output interface (306) to the medical network (106); The device is further configured to:

[0038] In a 28th aspect related to the preceding aspect, the data manager (302) receiving third medical device data (303) from one of the other digital communication modules (102A); transmitting the third medical device data (303) to the EMR server (108) via the communication coupling of the output interface (306) to the medical network (106); The device is further configured to:

[0039] In a 29th aspect of any one of the preceding two aspects, the data manager (302) designating the new first digital communication module (102) as a node gateway for transmission of said medical device data (303); designating the new digital communication module (102) as the node gateway after receiving a power-off message from the first digital communication module (102) and determining that the new digital communication module (102) has the earliest date / time indication among the other digital communication modules (102A); The device is further configured to:

[0040] In a 30th aspect related to the preceding aspect, the data manager (302) is further configured to disable the communication coupling to the EMR server (108) via the output interface (306) after designating the new first digital communication module (102) as the node gateway.

[0041] In a thirty-first aspect according to any one of the preceding aspects, the data manager (302) receiving first disposable or consumable usage information from the medical device; receiving second disposable or consumable item usage information from the other digital communication module (102A); combining the first and second disposable or consumable item usage information; transmitting the combined first and second disposable or consumable item usage information to at least one of the EMR server (108) and a medical supply server via the communication coupling of the output interface (306) to the medical network (106); The device is further configured to:

[0042] In a thirty-second aspect related to the preceding aspect, the digital communication module (102) further comprises a database and a log manager (334) that maintains a log file in the database (324) that tracks disposable / consumable item usage.

[0043] In a thirty-third aspect relating to any one of the preceding two aspects, the first and second disposable or consumable item usage information includes information indicating use of a filter, a disposable cassette, a line set, a dialysis solution, saline, a renal replacement solution, a warmer bag, or a disposable sensor.

[0044] In a thirty-fourth aspect according to any one of the preceding three aspects, the processor (107) monitors the treatment delivery through the medical device, and in particular, at the end of a treatment session: The type and number of single-use disposable items, such as disposable line sets, that have been used and must be replaced to perform subsequent procedures; and / or The type and number of semi-disposable elements that must be used up or replaced, such as concentrates for dialysate preparation or ultrafiltration, and / or The type and number of failed components, such as sensors or actuators, that must be replaced; configured to determine first disposable or consumable item usage information including: The processor (107) stores the first disposable or consumable item usage information in the memory, and the first disposable or consumable item usage information is transferred to the digital communication module (102) through the communication unit.

[0045] In a thirty-fifth aspect relating to any of the above four aspects, the data manager (302) of each digital communication module (102) of the plurality of digital communication modules (102A-0, ..., 102A-6) is configured to communicate its disposable or consumable item usage information to other digital communication modules, and each digital communication module maintains fleet aggregate information about all medical devices associated with its respective digital communication module portion of the wireless proprietary network (400).

[0046] In a thirty-sixth aspect relating to any one of the preceding five aspects, the digital communication module (102) receives an indication of available inventory input into at least one of the medical devices or received from a server of the medical network (106) via the medical network interface (310), and the data manager (302) compares the disposable or consumable item usage information with the indication of available inventory and generates a replenishment message including information on disposable items or consumable items that need to be replenished, and the replenishment message is sent to the medical network (106) for inventory tracking with a supplier.

[0047] In a thirty-seventh aspect related to any one of the preceding aspects, the wireless proprietary network (400) includes at least one of a Bluetooth® wireless protocol, a Bluetooth® mesh wireless protocol, a Bluetooth® 5.0 wireless protocol, a Zigbee® wireless protocol, a Z-Wave® wireless protocol, a WeMo® wireless protocol, and a low-power wide area network ("LPWAN") wireless protocol; The medical network (106) includes at least one of a Wi-Fi network and an Ethernet network.

[0048] In a thirty-eighth aspect relating to any one of the preceding aspects, the configuration file (332) specifies a destination network address of the EMR server (108), an identification of the medical device (104) type of the connected medical device (104), an identification of the medical device (104) serial number, and a timestamp when the received medical data was generated by the medical device (104) or received by the data manager (302) from the medical device (104).

[0049] In a thirty-ninth aspect according to any one of the preceding aspects, the data manager (302) receiving a stream of said medical device data (303); creating snapshots of said medical device data (303) at regular intervals; providing the snapshot of the medical device data (303) as the medical device data (303) transmitted to the first digital communication module (102); The device is further configured to:

[0050] In a fortieth aspect related to the preceding aspect, the periodic intervals have a duration between 5 seconds and 60 seconds.

[0051] In a forty-first aspect according to any one of the preceding two aspects, the data manager (302) using event tracking to identify changes to said medical device data (303) between snapshots; including only the changed medical device data (303) from a previous snapshot as the medical device data (303) transmitted to the first digital communication module (102); The device is further configured to:

[0052] In a forty-second aspect relating to any one of the preceding aspects, the medical device (104) includes at least one of a continuous renal replacement therapy ("CRRT") machine, a peritoneal dialysis machine, a hemodialysis machine, a water purification machine, and a nutritional preparation machine.

[0053] In a forty-second aspect relating to any one of the preceding aspects, the digital communication module (102) is configured to receive medical device data (303) from the medical device, and communication between the digital communication module (102) and the medical device is unidirectional.

[0054] In a forty-third aspect according to any one of the preceding aspects, the medical device data (303) comprises: event information including transitions between fill, dwell, and drain phases of a dialysis cycle; alarm, alert, or event information; treatment programming information; medical procedure data including at least one of an estimated fill rate, a drain rate, and an amount of ultrafiltration removed; It includes at least one of the following:

[0055] In a forty-fourth aspect according to any one of the preceding aspects, the data manager (302) receiving a configuration message via the output interface (306), the configuration message indicating a network address of a clinician device and criteria for sending notifications to the clinician device; determining that at least a portion of the medical device data (303) meets the criteria; sending a notification message to the clinician device over the proprietary network (400) indicating the at least a portion of the medical device data (303) that meets the criteria; The device is further configured to:

[0056] In a forty-fifth aspect according to any of the preceding aspects, the medical system or module further includes at least one other medical device that is an infusion pump, and the medical device (104) is a dialysis machine; the at least one other digital communication module (102A) is associated with each of the infusion pumps; the medical device data (303) from the dialysis machine includes a patient identifier, and the second medical device data (303) from the at least one infusion pump includes the same patient identifier and an infusion rate; The data manager (302) receiving an indication that adaptive liquid removal operation is enabled; · The flow rate of unused dialysate entering the filtration unit; an output flow rate from the filtration unit; and Pre-infusion flow rate into the extracorporeal blood circuit and -Post-infusion flow rate into the extracorporeal blood circuit and - The target amount and duration of liquid removal, Liquid removal rate and receiving parameter data associated with the patient identifier, the parameter data including one or more of: receiving the second medical device data (303) from the at least one other digital communication module (102A) via the wireless proprietary network (400); determining whether the at least one infusion pump is associated with the same patient identifier; determining an amount of fluid being infused or an infusion rate of the fluid being infused to the patient based on the second medical device data (303); determining updated parameter data based on the amount or infusion rate of fluid being infused into the patient determined from the parameter data and the second medical device data (303), in particular the updated parameter data taking into account the fluid infused by the infusion pump to maintain a consistent patient fluid balance during dialysis; transmitting the updated parameter data to the dialysis machine via the input interface (304); The device is further configured to:

[0057] In the forty-sixth aspect of the preceding paragraph, the data manager (302) Either the target amount of fluid removal and the removal period, or a patient fluid removal rate associated with said patient identifier; receiving parameter data associated with the patient identifier, said updated parameter data being i) the liquid removal target and the removal period, or the liquid removal rate; ii) the amount of fluid being infused into the patient or the infusion rate; and at least one updated flow rate, such as the fluid removal rate, for the dialysis machine based on transmitting the at least one updated flow rate, such as the updated fluid removal rate, to the dialysis machine via the input interface (304); The device is further configured to:

[0058] In a forty-sixth aspect related to the preceding aspect, determining the at least one updated flow rate includes recalculating one or more flow rates for the dialysis machine to maintain the patient's fluid balance unchanged, the one or more flow rates including one or more of: an unused dialysate flow rate entering a filtration unit; an output flow rate leaving the filtration unit; a pre-infusion flow rate into the extracorporeal blood circuit; a post-infusion flow rate into the extracorporeal blood circuit; and a fluid removal rate.

[0059] For example, either the pre-infusion flow rate or the post-infusion flow rate may be reduced with the same amount of infusion flow rate from the infusion pump, thereby keeping all other flow rates unchanged. Alternatively, the patient fluid removal rate may be increased with the same amount of infusion flow rate from the infusion pump, thereby keeping all other flow rates unchanged. Of course, any other combination of fluid changes that maintains patient fluid balance unchanged may be used.

[0060] In a forty-seventh aspect related to the preceding aspect, the dialysis machine is a CRRT machine, and the data manager (302) is configured to receive the fluid removal rate for a patient associated with the patient identifier and determine an updated fluid removal rate for the dialysis machine based on the fluid removal rate and the amount of fluid being infused into the patient or the infusion flow rate.

[0061] In a forty-eighth aspect relating to any one of the preceding two aspects, the transmission of the updated fluid removal rate causes the dialysis machine to display a recommendation on a screen indicating the updated fluid removal rate.

[0062] In a forty-ninth aspect relating to any one of the preceding three aspects, the transmission of the updated fluid removal rate causes the dialysis machine to automatically update a programmed treatment based on the updated fluid removal rate and causes the processor to drive the actuator to achieve the updated fluid removal rate.

[0063] In a 50th aspect relating to any one of the preceding four aspects, the processor (107) of the dialysis machine is configured to compare the updated fluid removal rate with a maximum allowable fluid removal rate and to display an alert if the updated fluid removal rate exceeds the maximum allowable fluid removal rate.

[0064] In a fifty-first aspect relating to the preceding aspect, if the updated liquid removal rate exceeds the maximum allowable liquid removal rate, the processor (107) recommends a liquid removal rate substantially equal to the maximum allowable liquid removal rate.

[0065] In a fifty-second aspect according to any one of the preceding aspects, the data manager (302) receiving sensor data from the EMR server (108) via the medical network (106); transmitting the sensor data to the medical device (104) via the input interface (304) for display on a screen of the medical device (104); The device is further configured to:

[0066] In a fifty-third aspect according to any one of the preceding aspects, the data manager (302) comparing the sensor data and at least a portion of the medical device data (303) to stored criteria; and transmitting, via the input interface (304), at least one recommendation message to the medical device (104), which causes information indicative of the comparison to be displayed on the screen.

[0067] In a 54th aspect relating to either one of the preceding two aspects, sensor data from the EMR server (108) is sent to a mailbox (340) of the digital communication module (102), and in particular, the sensor data from the EMR server (108) cannot be written directly to the medical device (104).

[0068] In a fifty-fifth aspect related to the preceding aspect, the medical device manager (336) processes the sensor data in the mailbox to determine what data should be sent to the medical device (104), and in particular, the medical device manager (336) converts the data into a compatible format and sends it to the processor (107) of the medical device (104).

[0069] In a fifty-sixth aspect relating to any one of the preceding aspects 53 to 55, the data manager (302) comparing an id code of the sensor data identifying a patient with patient identification information included in the medical device data transmitted by the medical device; transmitting the sensor data to the medical device (104) via the input interface (304) if the ID code and the patient identification information identify the same patient; The device is further configured to:

[0070] The DCM disclosed herein is configured as a gateway (such as an Internet of Things (“IoT”) gateway) that allows meshed DCMs to communicate with each other separately from a healthcare facility's medical network. As disclosed herein, the DCM provides a self-contained network without the need for other networking components such as switches, routers, gateways, and / or access points. Such a self-contained configuration allows the DCM to be deployed separately from and / or on top of an established medical network without any modifications to the medical network. Such a self-contained configuration also allows the DCM to be deployed in locations without an established network infrastructure, such as rural or remote areas.

[0071] As disclosed herein, the DCM is configured to provide a validity communication network (e.g., a private personal area network). In some embodiments, the DCM may implement the validity communication network using a wireless protocol such as Bluetooth®, Bluetooth® mesh, Bluetooth® low energy, Bluetooth® 5.0, Zigbee®, Z-Wave®, WeMo®, and / or LoRa (a low-power wide area network (“LPWAN”) network protocol). In other examples, the validity communication network may use a protocol specified by the medical device manufacturer.

[0072] In certain embodiments, the DCM receives medical procedure data and / or medical event data (collectively referred to herein as medical device data) from a processor or therapy module of a medical device, such as a continuous renal replacement therapy ("CRRT") machine. The DCM transmits at least one stream of the medical device data to a medical network for inclusion in an appropriate EMR. The medical device data may be in JavaScript Object Notation ("JSON") format, Hypertext Markup Language ("HTML") format, Extensible Markup Language ("XML") format, Comma Separated Values ​​("CSV") format, text format, and / or Health Level 7 ("HL7") format.

[0073] In some embodiments, the DCMs of medical devices are configured to communicate with each other over a validity communication network separate from the hospital network. The DCMs may send ping messages to identify other DCMs in the validity communication network. In some embodiments, the DCMs may designate one DCM as a node gateway that connects to the medical network. In these embodiments, the DCMs send medical device data to the designated node gateway DCM, which routes the received medical device data to the medical network. This configuration of the DCMs provides a singular point of connectivity to the medical network, thereby improving security for the DCMs and reducing network complexity.

[0074] The interconnectivity of the DCMs disclosed herein provides improved usability for healthcare providers. In one example, the DCMs are configured to track the usage of disposable and / or consumable items, such as filters, cassettes, line sets, dialysis solution, renal replacement solution, warmer bags, etc. DCMs within the same proprietary communication network may share disposable and / or consumable item usage information or provide such information to a designated node gateway DCM. At periodic intervals, one of the DCMs, such as the node gateway DCM, communicates the total usage information to the healthcare network and / or a refill server.

[0075] It should be understood that the DCMs disclosed herein may be included within or connected to more than one type of medical device. In one example, one DCM may be connected to a CRRT machine, and one or more DCMs may be provided with an infusion pump. Exemplary DCMs communicate over a validity communications network to determine which DCMs are associated with or providing treatment to the same patient (using patient identifiers entered into the CRRT machine and infusion pump). The DCMs then communicate medical device data with each other (or the infusion pump's DCM communicates data to the CRRT machine's DCM), which provides a more comprehensive, data-based picture of the patient's treatment. In one example, the CRRT machine's DCM uses infusion rate data from the infusion pump to set and / or modify the patient's fluid removal rate to meet programmed fluid removal targets. In this configuration, communication of infusion data and modification of the patient's CRRT treatment occurs outside of the medical network, thereby enabling such operability to be provided over a validity communications network provided by compatible medical devices.

[0076] In another embodiment, an exemplary DCM (connected to a CRRT machine) may communicate with a medical facility's EMR system via a medical network. Certain medical devices, such as blood pressure monitors or blood gas analyzers, are configured to transmit measurement data to the EMR system via the hospital network. The EMR system may transmit the measurement data to the DCM. In some examples, the DCM causes the received data to be displayed on the CRRT machine. In other examples, the DCM is configured to analyze the received data in combination with data from the CRRT machine to determine treatment recommendations that are displayed on the CRRT machine's monitor. In a further example, the DCM is configured to analyze the received data in combination with data from the CRRT machine to determine treatment adjustments, which are then transmitted to the CRRT machine to adjust ongoing treatment.

[0077] In a further embodiment, the exemplary DCM (connected to or integrated with the CRRT machine) may be configured to provide an indication of medical device data to a clinician's clinician device (e.g., a smartphone or tablet computer). In this example, the clinician device may be wirelessly coupled to the DCM via a validity communications network rather than through a hospital network. Through configuration, the DCM is provided with the clinician device's network or hardware address and an indication of what information should be sent. The DCM receives medical device data from the CRRT machine's therapy processor and determines whether any conditions for sending a notification are met. The DCM is configured to send a notification message containing information indicative of the medical device data to a designated clinician device via the validity communications network if at least one condition is met. Such a configuration allows a medical device provider to provide remote alerts and / or alarms directly to a clinician via the exemplary DCM without throttling or restricting operation for the medical network or relying on the medical network to route the alerts and / or alarms to the appropriate clinician.

[0078] In the above embodiment, the DCM may communicate with the clinician device via a first protocol, such as Bluetooth®, which is provided in many mobile devices. Additionally, the DCM may communicate with other DCMs using a different protocol and / or a proprietary protocol that is not common in mobile devices. Such a configuration allows for integration of DCMs that communicate over a proprietary network with mobile devices that have relatively more limited transceiver options for wireless communication.

[0079] Exemplary DCMs may operate with any type of medical device or machine applicable to, for example, fluid delivery for plasma exchange, hemodialysis ("HD"), hemofiltration ("HF"), hemodiafiltration ("HDF"), and continuous renal replacement therapy ("CRRT") treatments. The DCMs described herein may also be applicable to peritoneal dialysis ("PD"), intravenous drug delivery, and nutrient fluid delivery. The different treatment modalities and associated devices described above may be referred to herein collectively or generally individually as medical fluid delivery or treatments and associated devices or machines.

[0080] The above modalities may be provided by a medical fluid delivery machine that houses the components required to deliver the medical fluid, such as one or more pumps, valves, heaters as needed, online medical fluid generation equipment as needed, any one or more sensors such as pressure sensors, conductivity sensors, temperature sensors, air detectors, blood leak detectors, etc., a user interface, and a control unit that may employ one or more processors and memory to control the above equipment. The medical fluid delivery machine may also include one or more filters, such as a dialyzer or hemofilter for cleansing the blood, and / or an ultrafilter for purifying water, dialysate, or other treatment fluids.

[0081] The DCM and medical fluid delivery machines described herein may be used in conjunction with home-based machines. For example, the system may be used in conjunction with a home HD, HF, HDF, or PD machine operated for the patient's convenience. One such home system is described in commonly assigned U.S. Patent No. 8,029,454 (the "'454 Patent"), entitled "High Convection Home Hemodialysis / Hemofiltration And Sorbent System," filed November 4, 2004, and issued October 4, 2011. Another such home system is described in commonly assigned U.S. Patent No. 8,393,690 (the "'690 Patent"), entitled "Enclosure for a Portable Hemodialysis System," filed August 27, 2008, and issued March 12, 2013. The entire contents of each of the above references are incorporated herein by reference.

[0082] As described in detail below, the DCM of the present disclosure may operate within a comprehensive healthcare network that may include many different types of devices, patients, clinicians, physicians, service personnel, electronic medical record ("EMR") databases, websites, resource planning systems that handle data generated through patient and clinician communications, and business intelligence. The DCM of the present disclosure operates seamlessly within the healthcare network without violating the network's rules and protocols.

[0083] Therefore, in light of the present disclosure and the above aspects, it is an advantage of the present disclosure to provide a self-contained proprietary wireless network hosted by a digital communication module (e.g., an IoT gateway) associated with a medical device.

[0084] Another advantage of the present disclosure is the use of a self-contained network for transmitting medical device data and / or consumable / disposable usage data between digital communication modules for single-point transmission to the medical network.

[0085] A further advantage of the present disclosure is the use of digital communication modules for edge computing regarding decision support for CRRT machines.

[0086] Yet another advantage of the present disclosure is to provide a system that provides wireless alerts, alarms, or other notifications from a medical device directly to a mobile clinician device.

[0087] Further features and advantages are described in and will be apparent from the following detailed description and drawings. The features and advantages described herein are not all-inclusive, and many additional features and advantages will become apparent to those skilled in the art, particularly 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 ease of reading and explanation, and not to limit the scope of the inventive subject matter. [Brief explanation of the drawings]

[0088] [Figure 1] 1 is a diagram of a DCM environment including a DCM and a medical device, according to an exemplary embodiment of the present disclosure.

[0089] [Figure 2] FIG. 2 is another diagram of a DCM environment, according to an exemplary embodiment of the present disclosure.

[0090] [Figure 3] 3 is a diagram of the exemplary DCM of FIGS. 1 and 2 in accordance with an exemplary embodiment of the present disclosure.

[0091] [Figure 4] 1 is a diagram of an exemplary proprietary communication network hosted by multiple DCMs, according to an exemplary embodiment of the present disclosure.

[0092] [Figure 5] 5 is a data flow diagram illustrating a messaging protocol for the proprietary communication network of FIG. 4 when DCM is activated, in accordance with an exemplary embodiment of the present disclosure.

[0093] [Figure 6] 6 illustrates at least a portion of a configuration file that exists after the activated DCM of FIG. 5 is registered, according to an exemplary embodiment of the present disclosure.

[0094] [Figure 7] FIG. 5 is a data flow diagram illustrating a messaging protocol for the proprietary communication network of FIG. 4 when the DCM is powered off, in accordance with an exemplary embodiment of the present disclosure.

[0095] [Figure 8] FIG. 5 is a diagram of an embodiment in which the proprietary communications network of FIG. 4 is used to track the use of disposable or consumable items in a medical device, according to an exemplary embodiment of the present disclosure.

[0096] [Figure 9] FIG. 5 is a diagram of the proprietary communication network of FIG. 4 configured for patient fluid management, according to an exemplary embodiment of the present disclosure.

[0097] [Figure 10] FIG. 10 is a flow diagram of an exemplary procedure for calculating liquid removal rate using the proprietary communication network of FIG. 9, according to an exemplary embodiment of the present disclosure.

[0098] [Figure 11] FIG. 4 is a diagram of the DCM of FIGS. 1-3 configured to provide clinician decision support, according to an exemplary embodiment of the present disclosure.

[0099] [Figure 12]5 illustrates how the proprietary communications network of FIG. 4 is used to provide notification messages to clinician devices, according to an exemplary embodiment of the present disclosure.

[0100] [Figure 13] 13 illustrates how the DCM of FIGS. 1-3 may be configured to send a notification message to the clinician device of FIG. 12 according to an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0101] Disclosed herein are methods, systems, and devices for hosting or otherwise providing a validity wireless communication network separate from a medical network. The methods, systems, and devices are implemented in one embodiment via a gateway-like digital communications module ("DCM"). The exemplary DCM disclosed herein may be integrated within a medical device or provided separately from the medical device. In either configuration, the DCM is configured to receive medical device data from the medical device. The DCM transmits the medical device data to the hospital network for storage in a patient record managed by an EMR server.

[0102] An exemplary DCM is provisioned via a configuration file and / or configuration routines that specify input interface parameters, output interface parameters, device driver parameters, and / or data conversion parameters. The configuration file and / or configuration routines also define how the DCM communicates with other DCMs in the validity wireless communication network. Together, DCMs in the same validity wireless communication network may form a mesh network, where the network is self-contained and hosted exclusively by the DCM without using the hospital network infrastructure.

[0103] The DCM can be configured to operate with many different types of medical devices and communicate via different types of interfaces, such as a serial connection (e.g., an RS-232 or RS-485 connection), an Ethernet connection, a Wi-Fi connection, a Bluetooth® connection, a universal serial bus (“USB”) connection, or any other wireless connection disclosed herein. The configurability of the DCM allows for its use with many different types of medical devices, such as peritoneal dialysis machines, critical care dialysis machines, continuous renal replacement therapy (“CRRT”) machines, hemodialysis machines, water preparation / purification devices, nutritional compounding machines, infusion pumps, and the like. Furthermore, the configurability of the DCM allows for its use within differently configured hospital systems. Thus, the configurability of the DCM allows medical device data to be transmitted to a medical network without the need for connectivity or network changes to the medical device or hospital system.

[0104] Reference is made herein to medical device data. As disclosed herein, medical device data is generated at a medical device and transmitted to a DCM. Medical device data includes treatment programming information. The treatment programming information includes one or more parameters that define how a medical device should operate to administer treatment to a patient. For CRRT treatment, the parameters may specify the flow rate of fresh dialysate, the total fluid volume (or volume per bag) of dialysate, the dialysate concentration of one or more substances, the desired dialysis dose, particularly in terms of flow rate (such as drain flow rate, urea clearance, etc.), the total number of fresh dialysis bags connected to the CRRT medical device, the target UF removal, the blood flow rate, the total number of connected drain bags, hemofilter or dialyzer information, the volume and / or flow rate of substitution fluid, and / or the amount (and / or rate) of heparin or other pharmaceutical / additives to be added to the patient's recirculating blood.

[0105] For peritoneal dialysis treatments, parameters may specify the amount (or rate) of unused dialysate to be pumped 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 dialysate and ultrafiltration ("UF") to be pumped or drained from the patient after the dwell period has ended. For treatments using multiple cycles, parameters may specify the fill, dwell, and drain volumes for 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 during the day and night). In addition, parameters may specify the date / time / day of the week (e.g., schedule) on which treatments should be administered by the medical fluid delivery machine. Furthermore, parameters for a given treatment may specify the total volume of dialysate to be administered for each treatment, in addition to the dialysate concentration level, such as the dextrose level. For infusion therapy, parameters may include the volume to be infused, the drug to be infused, the drug concentration, the drug dosage, and / or the infusion rate.

[0106] Medical device data also includes event information related to the administration of treatment. Event information may include data generated by the medical device indicating measured, detected, or determined parameter values. For example, a prescribed treatment may specify that five separate cycles, each with a 45-minute dwell time, should be administered, but the medical fluid delivery device may administer a treatment in which fewer cycles, each with a 30-minute dwell time, are provided. The medical device monitors how the treatment is administered and provides parameters indicative of operation accordingly. Parameters for treatment data may include, for example, the total volume of dialysate administered to the patient, blood flow rate, dialysate flow rate, dialysate volume, substitution flow rate, spent dialysate for effluent flow rate, anticoagulant (e.g., citrate or heparin) flow rate, calcium flow rate, dialysate temperature, intravenous drug flow rate, number of cycles administered, fill volume per cycle, dwell time per cycle, drain time / volume per cycle, estimated amount of UF removed, treatment start time / date, and / or treatment end time / date. Treatment data may be prescribed or calculated, such as fill and drain rates determined by dividing the volume of fluid pumped by the time spent pumping. Treatment / event data may further include identification of alarms that occurred during treatment, the duration of the alarm, the time of the alarm, the event associated with the alarm, and / or an indication of whether the problem that caused the alarm was resolved or whether the alarm was silenced.

[0107] Medical device data further includes device mechanical logs containing diagnostic information, fault information, etc. Diagnostic information may 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. Medical device data may be transmitted as a data stream or may be provided at regular intervals. In some examples, medical device data may be transmitted upon the occurrence of an event or other change to the data.

[0108] Also referenced herein is log data generated by the example DCMs disclosed herein, which log data may include an identification of the therapy device type, an identification of the therapy device serial number, a timestamp at which therapy data is generated or received from the therapy device, an identifier of the DCM, a timestamp for the snapshot, and / or a DCM monotonic timestamp. I. DCM environment implementation

[0109] 1 shows a diagram of a DCM environment 100 according to an exemplary embodiment of the present disclosure. The exemplary DCM environment 100 includes at least one DCM 102 communicatively coupled to a medical device 104. The DCM 102 may be connected to the medical device 104 via a serial connection, an Ethernet connection, a USB connection, a Wi-Fi connection, a Bluetooth® connection, etc. The exemplary DCM 102 may include a network gateway, such as an IoT gateway.

[0110] In the exemplary embodiment, the DCM 102 is configured to receive medical device data from the medical device 104. This unidirectional communication configuration prevents another device from accessing, programming, or otherwise communicating with the medical device 104 through the DCM 102. However, in some embodiments, the DCM 102 may have a bidirectional communication link with the medical device 104 to allow data, program instructions, or information to be transmitted to the medical device. While only one DCM 102 and medical device 104 are shown in FIG. 1 , it should be understood that the environment 100 may include tens to hundreds or thousands of medical devices and respective DCMs forming a proprietary wireless communication network.

[0111] The exemplary medical device 104 is configured to accept one or more parameters that specify a treatment or prescription (i.e., treatment programming information). During operation, the medical device 104 writes event, diagnostic, and / or operational data to one or more log files. In some embodiments, the medical device 104 may store medical device data in the log files periodically, such as every 5 to 60 seconds and / or after a change in the data occurs. New medical device data written to the log files is transmitted to the DCM 102. In some embodiments, the medical device creates medical device data in JavaScript Object Notation ("JSON"), Hypertext Markup Language ("HTML") format, Extensible Markup Language ("XML") format, Comma Separated Values ​​("CSV") format, text format, and / or Health Level 7 ("HL7").

[0112] The exemplary medical device 104 may include one or more control interfaces 105 for displaying instructions and receiving control input from a user. The control interface 105 may include buttons, a control panel, or a touch screen. The control interface 105 may also be configured to allow a user to navigate to particular windows or user interfaces on the screen of the medical device 104. The control interface 105 may also provide instructions for operating or controlling the medical device 104.

[0113] The exemplary medical device 104 also includes a processor or therapy module 107. The processor or therapy module 107 of the medical device 104 operates according to one or more instructions to perform a treatment on the patient. The instructions may be obtained via the control interface 105. The processor or therapy module 107 also monitors the device components for issues that are documented as diagnostic information. The processor or therapy module 107 generates medical device data in combination with operating one or more pumps or other components to perform a treatment. The processor therapy module 107 transmits the medical device data to the DCM 102.

[0114] The exemplary DCM environment 100 also includes a medical network 106, which communicatively couples the DCM 102 to an EMR server 108 and one or more hospital systems 110. The medical network 106 may include any number of gateways, routers, system hubs, switches, and / or networking equipment for establishing communication connections and routing data. The medical network 106 may also include one or more firewalls that restrict access to only authorized remote devices and / or servers. The medical network 106 may include any local area network ("LAN"), wireless LAN ("WLAN"), Ethernet network, Wi-Fi network, or combination thereof.

[0115] 1, the DCM 102 may be coupled to the medical network 106 either wired or wirelessly. In some embodiments, the connection may include an Ethernet connection, a Wi-Fi connection, and / or a cellular connection. Additionally or alternatively, the DCM 102 may have a serial connection to the EMR server 108 (or hospital system 110) that bypasses the medical network 106.

[0116] FIG. 2 shows another diagram of the DCM environment 100, according to an exemplary embodiment of the present disclosure. In this embodiment, the DCM 102 is included within and / or integrated with the medical device 104. The DCM 102 may include, for example, a Digi ConnectCore® 6UL module with an NXP i.MX6UL-2, Cortex-A7 528MHz CPU, 256MB / 1GB NAND, and a DDR3 flash drive. The DCM 102 may be connected to the medical device 104's communications bus to receive medical device data. The DCM 102 (including the DCM of FIG. 1) also includes an 802.11a / b / g / n / ac Wi-Fi radio and / or a Bluetooth® 4.2 radio. The DCM 102 may include the Yocto Linux® operating system and includes drivers for the Digi chipset.

[0117] 1 and 2 is configured to manage patient EMRs stored in a database in a memory device 112. The EMR server 108 is configured to receive medical device data, parse the data based on a patient identifier, locate the corresponding patient EMR in the memory device 112, and store the parsed medical device data in the identified EMR. The EMR server 108 may also access one or more EMRs in response to a request message identifying a respective patient. The EMR server 108 may store the medical device data in HL7 format, Binary Version 2 format, Binary Version 3 format, or First Healthcare Interoperability Resource (“FHIR”) format.

[0118] The exemplary hospital system 100 may include any of a service portal, an enterprise resource planning system, a web portal, a business intelligence portal, a HIPAA-compliant database, a pharmacy system, etc. The hospital system 100 may also include a middleware system and / or an integration engine. The hospital system 100 allows user devices (e.g., smartphones, laptop computers, workstations, tablet computers, etc.) to read and / or write medical device data stored in the EMR of the memory device 112.

[0119] In the illustrated example, the medical device 104 is a PrisMax™ CRRT machine manufactured by Baxter International, Inc. It should be understood that in other embodiments, the medical device 104 may include any other renal failure therapy machine, infusion pump, physiological sensor, etc. The medical device 104 may include, for example, 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 nutritional compounder, an oxygen sensor, a respiratory monitor, a glucose meter, a blood pressure monitor, an electrocardiogram (“ECG”) monitor, a weight scale, and / or a heart rate monitor.

[0120] Regarding renal failure treatment machines, a patient's renal system may fail due to a variety of causes. Renal failure results in several physiological disorders. For example, a patient experiencing renal failure can no longer balance water and minerals or excrete their daily metabolic load. Toxic end products of nitrogen metabolism (urea, creatinine, uric acid, etc.) can accumulate in the patient's blood and tissues. Renal failure and reduced kidney function are treated by dialysis. Dialysis removes waste, toxins, and excess water from the body that normally functioning kidneys would otherwise remove. Dialysis treatment for kidney function replacement is important for many people because the treatment is lifesaving.

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

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

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

[0124] Another type of kidney failure treatment is peritoneal dialysis, in which a dialysis solution, also called dialysate, is infused into a patient's peritoneal cavity via a catheter. The dialysate contacts the peritoneal membrane of the peritoneal cavity. Waste, toxins, and excess water pass from the patient's bloodstream through the peritoneal membrane and into the dialysate due to diffusion and osmosis, i.e., an osmotic gradient is created across the membrane. An osmotic agent in the dialysis provides the osmotic gradient. The used or spent dialysate is pumped out of the patient, removing the waste, toxins, and excess water from the patient. This cycle may be repeated, for example, multiple times.

[0125] There are various types of peritoneal dialysis therapies, including continuous ambulatory peritoneal dialysis ("CAPD"), automated peritoneal dialysis ("APD"), as well as tidal flow dialysis and continuous flow peritoneal dialysis ("CFPD"). CAPD is a manual dialysis procedure. In this, a patient manually connects an implanted catheter to a drain to drain used or spent dialysate from the peritoneal cavity. The patient then connects the catheter to a bag of fresh dialysate to infuse the 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 cavity, where waste, toxins, and excess water transfer occurs. After the dwell period, the patient repeats the manual dialysis procedure, for example, four times a day, with each treatment lasting approximately one hour. Manual peritoneal dialysis requires significant time and effort from the patient, leaving ample room for improvement.

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

[0127] APD machines pump used or spent dialysate from the peritoneal cavity, through a catheter, and into a drain. Similar to the manual process, several drain, fill, and dwell cycles occur during dialysis. A "final fill" occurs at the end of APD, and the dialysate remains in the patient's peritoneal cavity until the next treatment.

[0128] The present system and associated methods are applicable to any of the renal failure treatment modalities listed above. II. DCM embodiment

[0129] 3 shows a diagram of the example DCM 102 of FIGS. 1 and 2 in accordance with an example embodiment of the present disclosure. The example DCM 102 includes a data manager 302 and an input interface 304 for communicatively coupling with a medical device 104. The input interface 304 may include at least one of a serial input port, an Ethernet port, and / or a wireless input port. The input interface 304 may include a wired or wireless transceiver for communication with the medical device 104. In some embodiments in which the DCM 102 is integrated within the medical device 104, the input interface 304 may connect to a data bus or an output connector on a PCB board of the medical device 104.

[0130] The input interface 304 is configured to receive medical device data 303 from the medical device, which is routed to the data manager 302. In some embodiments, as described below, the input interface 304 may also be configured to transmit information for display on a screen or control interface 105 of the medical device 104. Additionally or alternatively, the input interface 304 may transmit instructions to modify treatment parameters or treatment controls provided by the treatment module 107 of the medical device 104.

[0131] The example data manager 302 is configured to route the medical device data 302 to an appropriate port on the output interface 306. The routing depends on the configuration of the DCM 102. For example, the output interface 306 includes a medical network interface 310 for instances where the medical device data 303 is routed to the EMR server 108 via the medical network 106. The medical network interface 310 may include a wired and / or wireless Ethernet transceiver, a Wi-Fi transceiver, and / or a serial transceiver for an RS-232 or RS-485 connection to the medical network 106. The data manager 302 is configured to select the medical network interface 310 in instances where the medical device data 303 is routed directly to the EMR server 108 rather than through another DCM 102A via a proprietary communications network.

[0132] The example output interface 306 includes a proprietary network interface 312 for routing medical device data 303 to other DCMs 102A over a proprietary communications network. The proprietary network interface 312 may include a transceiver configured for communication via at least one of Bluetooth, Bluetooth mesh, Bluetooth low energy, Bluetooth 5.0, Zigbee®, Z-Wave®, WeMo®, and / or LoRa. The proprietary network interface 312 is configured to enable DCMs within communication range of each other to form a proprietary communications network separate from the medical network 106 shown in FIGS. 1 and 2. As described in detail below in connection with at least FIGS. 4 through 11, the data manager 302 selects the proprietary network interface 312 for transmission of medical device data 303 when conditions and / or configurations dictate that data be transmitted to other medical devices / DCMs 102A.

[0133] The exemplary output interface 306, in some embodiments, includes a clinician device interface 314, which allows the medical device data 303 (and / or notifications from the notification processor 316) to be sent to the clinician device 322. The clinician device interface 314 may include a transceiver configured to communicate via at least one of Bluetooth, Bluetooth mesh, Bluetooth low energy, Bluetooth 5.0, Zigbee, and / or any other wireless protocol supported by the clinician device 322 (or a hardware attachment to the clinician device (such as a Zigbee transceiver interfacing with a USB or Lightning port)). The data manager 302 selects the clinician device interface 314 for the medical device data 303 and / or notifications for the clinician device 322.

[0134] The output interface 306 includes a clinician device interface 314 if communication with a clinician device is desired, but a proprietary communication network with other DCMs 102A is provided through a wireless network protocol not supported by the clinician device. In such a configuration, the data manager 302 uses the proprietary network interface 312 for communication between DCMs 102A over the proprietary communication network, while communication with clinician devices 322 is provided via the clinician device interface 314. In some embodiments, the clinician device interface 314 is omitted if communication with clinician devices 322 is not supported or required by the DCM 102. Furthermore, if communication with clinician devices may occur via the proprietary network interface 312, the clinician device interface 314 is omitted. For example, the proprietary communication network may implement a Bluetooth protocol supported by known clinician devices 322. Under this configuration, the clinician device 322 is made part of a proprietary communication network hosted by the DCM 102 and other DCMs 102A.

[0135] As described above, the DCM 102 of FIG. 3 includes a notification processor 316, which is communicatively coupled to the data manager and database 324. The exemplary notification processor 316 is configured to generate event and / or alarm notifications for the clinician device 322. The exemplary notification processor 316 compares medical device data 303 received from the medical device 104 to one or more criteria stored in the database 324. If at least one criterion is matched, the notification processor 316 generates a notification message for the appropriate clinician device 322. As described in more detail below, a clinician may use the clinician device 322 to access the notification processor 316, which may include one or more APIs to template notification forms in the database 324. The template notification form includes options for selecting criteria for receiving notification messages. The criteria may include, for example, a patient identifier, an event condition (such as a drain bag low or a medical device pause), an alarm condition (such as a line occlusion), and / or an alert condition (such as an end of treatment or a declining UF removal trend). The criteria may also include options for selecting the medical device data 303 (such as dialysis parameters) to send to the clinician device 322 and / or how much contextual information is needed to display in conjunction with the alarm / alert / event notification. Selection of criteria via a template causes the notification processor 316 to create logic, conditions, and / or thresholds to compare against the medical device data 303. The logic, conditions, and / or thresholds are stored in a criteria file in the database 324 and associated with the destination network address, hardware address, and / or identifier of the clinician device 322. After the criteria file is created, the notification processor accesses the file in the database 324 to determine when a notification message should be generated and what information to include in the message.

[0136] The example DCM 102 also includes a file configuration manager 330 that allows routing of medical device data 303 to be specified. The file configuration manager 330 stores at least one configuration file 332. In some embodiments, the file configuration manager 330 receives the configuration file 332 via the medical network interface 310 from a computer connected to the medical network 106 and / or from another DCM 102A via a proprietary network interface 312.

[0137] The configuration manager 330 reads the configuration file 332 and accordingly configures the log manager 334, medical device manager 336, notification processor 316, data manager 302, and / or output interface 306. For the log manager 334, this may include reading the configuration file 332 for DCM identifiers, medical device types, medical device identifiers, etc., which are written to registers, parameters, and / or variables of the log manager 334.

[0138] For the data manager 302 and output interface 306, this may include reading a configuration file 330 to determine which network interface 310-314 should receive the medical device data 303. In one example, the configuration file 332 may specify that the medical device data 303 should be routed to the medical network interface 310, for example, because the DCM 102 is designated as a node gateway or node for routing medical device data to the EMR server 108. In another example, the configuration file 332 may specify that the medical device data 303 should be routed to the proprietary network interface 312 because another DCM 102A is a node gateway. In this example, the configuration file 332 may include an identifier, network address, and / or hardware address of the recipient DCM 102A. In these examples, the configuration file manager 330 may determine which of the other DCMs 102A will receive the medical device data 303 based on a specified order, which may correspond to the activation date / time or the robustness of the connection to the medical network 106. The log manager 334 may determine the date / time at which the DCM 102 is activated or otherwise turned on (or the medical device 104 is activated), which is stored in the configuration file 332 to enable the configuration file manager 330 to determine which network interface 310 or 312 should receive the medical device data 303.

[0139] In these examples, the configuration file manager 330 is configured to at least partially host the proprietary network interface 312. The configuration file manager 330 may specify the conditions for connecting the DCM 102 to other DCMs 102A in the proprietary communications network through parameters in the configuration file 332, including networking protocols for specifying node identity broadcast messages, handshake messages, cross-network configuration messages, deactivation messages, and / or parameters for designated node gateways, message timeout durations, network failover conditions, transmit / receive channels / frequencies / sub-frequencies, and / or data rates. The information in the configuration file 332 specifies the parameters and protocols for the proprietary communications network established and hosted by the DCM 102 and other DCMs 102A.

[0140] In some examples, the configuration file manager 330 may also specify conversion file types for the network interfaces 310-314. Additionally, the configuration file manager 330 configures the data manager 302 based on the duration between snapshots, the types of medical device data to be included in separate streams and / or subsets, and / or the types of data to be received from the medical device 104 (e.g., JSON data, HTML data, binary data, HL7 data, XML data, etc.). The configuration file manager 330 also reads the configuration file 332 to specify network credentials, authentication information, encryption keys, API identifiers, destination IP addresses, etc. for the network interfaces 310-314.

[0141] The example log manager 334 of FIG. 3 creates and / or manages log data. As disclosed herein, the log data may include information indicative of the medical device 104, such as a medical device type identification, a medical device serial number identification, a timestamp when the medical device data 303 was generated or received from the medical device 104, a DCM 102 identifier, timestamps for snapshots (disclosed below) created by the device data manager 302, and a DCM monotonic timestamp. The medical device type identification, medical device serial number identification, and DCM 102 identifier may be specified in a configuration file 332. In some examples, the medical device type identification and medical device serial number identification may be reported by the medical device 104. The log manager 334 is configured to store this information and create appropriate timestamps when the medical device data 303 is received and / or snapshots are created. The log manager 334 may then send at least a portion of the log data to the data manager 302 for inclusion in the medical device data 303 routed to the designated interface 310-314.

[0142] In some embodiments, instead of processing / transmitting a continuous stream of medical device data, the example data manager 302 is configured to create snapshots of the medical device data 303 at discrete times. The time periods may be specified by the configuration file 332 and may include, for example, 5-second intervals, 10-second intervals, 30-second intervals, 60-second intervals, etc. For each snapshot, the data manager 302 reads the most recently received data from the medical device 104. In this way, the data manager 302 provides periodic updates on the status of the medical device 104.

[0143] In one example, the medical device 104 may send medical device data 303 in a continuous stream, at regular intervals, or after a change to the data. The medical device 104 may send medical device data 303 in a medical device log file or a stream of messages. The data manager 302 compiles the received data since the last snapshot interval. As the next interval approaches, the data manager 302 compiles the most recent data into a snapshot to provide a representation of the medical device 104 at that time. If multiple events occur during the compilation period, the data manager 302 may include only the most recent event or all of the events that occurred during the period.

[0144] In some examples, the data manager 302 may compare a current snapshot with a previous snapshot. Based on the comparison, the data manager 302 may include only medical device data that has changed since the previous snapshot in the current snapshot. The comparison reduces the amount of data transmitted in each snapshot so that only new and / or updated medical device data 303 is communicated. For example, a CRRT medical device 104 may continuously transmit an estimated UF removal value, dialysate delivered, substitution fluid delivered, and / or effluent removed. Thus, the data manager 302 includes the UF removal value only if there is a change in the value. In another example, an alarm may activate at a specific time. A device status indicating that the alarm is still active may be included in the medical device data 303. However, the data manager 302 may only include a notification in the first snapshot of the time (and alarm type) that the alarm became active, and include the time the alarm was silenced or reset in the subsequent second snapshot without including an indication that the alarm was active in the intermediate snapshots.

[0145] In other embodiments, the medical device 104 may selectively transmit only medical device data that has changed from a previous value or that reflects a new event. In such an example, the data manager 302 writes the received medical device data 303 to the appropriate snapshot.

[0146] The data manager 302 is configured to combine any log data with the medical device data 303 and then format the data into a data format compatible with or required by the EMR server 108, other DCMs 102A, and / or clinician devices 322. In other words, the data manager 302 creates a transformation of the medical device data 303 and / or log data. The transformation type may be specified by a configuration file 332. The transformation may be, for example, from JSON to HL7, binary, and / or FHIR. The data manager 302 may include one or more files and / or algorithms that specify how to transform the medical data 303 and / or log data in JSON, XML, HTTP, or HTML format, for example, to HL7, binary v2, binary v3, and / or FHIR. The files and / or algorithms may identify the JSON data by location, data label, field name, and / or metadata and specify how the data is transformed, including transformations of data label names, metadata names, numeric formats, location, etc. Thereafter, the data management unit 302 transmits the converted data to the specified interface 310-314.

[0147] In some embodiments, the DCM 102 is enabled for bidirectional communication with the medical device 104. An example medical device manager 336 of the DCM 102 is configured to process data and / or information for transmission to the medical device 104. The medical device manager 336 includes, for example, a mailbox 340 that allows external data or information to be written to the DCM 102 for transmission to the medical device 104. In other words, data from the EMR server 108 (or other DCMs 102A) is not written directly to the medical device 104. Rather, the data is written to or transmitted to the mailbox 340. The example medical device manager 336 processes the information in the mailbox 340 to determine what data or information should be transmitted to the medical device 104. In some embodiments, the mailbox 340 and / or criteria for transmission to the medical device 104 are stored in the database 324.

[0148] In one embodiment, the medical device manager 336 receives sensor or lab data related to a patient being treated by the medical device 104 from the EMR server 108. In some embodiments, the EMR server 108 may transmit the data to the medical network interface 310. In other embodiments, the data is received at the DCM 102 from another DCM 102A on a proprietary communications network (where one of the DCMs is connected to the EMR server 108 via the medical network 106). The data is transmitted to a mailbox 340. The medical device manager 336 compares the received data with criteria specified in the database 324. In one example, the medical device manager 336 determines that the received data meets the criteria for transmitting the data to the medical device. Accordingly, the medical device manager 336 converts the data into an appropriate format and transmits it to the treatment module 107 of the medical device 104 via the input interface 304, thereby causing the treatment module 107 to display the data on the control interface 105. In another example, the medical device manager 336 compares the received data (including any associated medical device data 303) with one or more conditions specified in the database 324 to determine a medical device recommendation. The medical device manager 336 sends one or more messages with the recommendations to the medical device 104 for display. The recommendations may specify recommended changes to the dialysis treatment, such as increasing the dwell time or changing the dextrose concentration of the dialysate. In yet another example, the medical device manager 336 uses the received data (including any associated medical device data 303) and one or more conditions specified in the database 324 to determine a treatment adjustment. The medical device manager 336 sends one or more messages with the treatment adjustment to the medical device's therapy module 107 to change or modify a current or future treatment (e.g., converting from a non-respiratory therapy to a respiratory therapy, increasing fill, dwell, or drain times, increasing / decreasing fluid removal rates, etc.).

[0149] In subsequent sections, reference is made to operations performed by components 302, 304, 306, 310, 312, 314, 316, 330, 334, and 336 of DCM 102. The exemplary operations performed by components 302, 304, 306, 310, 312, 314, 316, 330, 334, and 336 of DCM 102 may be implemented using one or more computer programs and / or applications. A program or application may be defined by a series of computer instructions stored on any computer-readable medium, including random access memory (“RAM”), read-only memory (“ROM”), flash memory, magnetic or optical disk, optical memory, or other storage medium. The instructions may be configured to be executed by a processor of DCM 102, which, when executing the series of computer instructions, performs or facilitates the execution of all or a portion of the disclosed methods and procedures disclosed herein. The persistent storage device or database 324 may include any memory device including RAM, ROM, flash memory, and the like. III. Exemplary Proprietary Communication Network Embodiments

[0150] As mentioned above, the example DCMs 102 of Figures 1-3 are configured to host or otherwise participate in a proprietary communications network separate from the medical network. Figure 4 shows a diagram of an example proprietary communications network 400 hosted by multiple DCMs, according to an example embodiment of the present disclosure. In the illustrated diagram, only DCMs 102 are referenced, with each DCM connected to a separate medical device 104 (i.e., a CRRT machine).

[0151] 4, the proprietary communications network 400 formed by the DCMs 102 includes a mesh network in which each DCM 102 may wirelessly communicate with other in-range DCMs. Any out-of-range DCMs may be connected to the network 400 through at least one other DCM. In another example, the DCMs 102 may configure themselves to communicate in an ordered sequence, such that each DCM acts as a router or switch between other DCMs.

[0152] In the illustrated embodiment, the DCMs 102 share the same proprietary communications network 400 protocol and can include additional DCMs as they come online and are within range of the network 400. FIG. 4 shows one DCM 102A-1, designated as a node gateway, provides the primary interface (via its medical network interface 310) to the EMR server 108 through the medical network 106. In this configuration, the other DCMs 102A-2 through 102A-6 send medical device data 303 to the DCM 102A-1 for transmission to the EMR server 108. The gateway node DCM 102A-1 provides a single point of connection access for the other DCMs 102A-2 through 102A-6, which reduces the number of ports required for connection to the medical network 106. This reduces configuration time as each DCM 102 is brought online because network credentials do not need to be installed. Alternatively, DCM 102 may share network credentials with new DCMs that are brought online as part of the protocol of proprietary communications network 400. The illustrated configuration also improves security by limiting network access to DCMs 102A-2 through 102A-6.

[0153] 5 illustrates a data flow diagram 500 depicting the messaging protocol of the proprietary communication network 400 when a DCM 102 is activated, according to an exemplary embodiment of the present disclosure. In the illustrated embodiment, initial DCMs 102A-1 and 102A-2 host the proprietary communication network 400. Also, 102A-1 is designated as the host gateway that communicates with the EMR server 108. In this example, the host gateway is determined based on which DCM 102 was activated earliest. In other examples, the host gateway may be determined based on which of the DCMs 102 has a more robust communication connection with the EMR server 108, and this DCM 102 is connected to a number of other DCMs, or any other configuration specified by the protocol of the proprietary communication network 400.

[0154] In this example, DCM 102A-3 comes online or is activated. This activation may occur when its corresponding medical device 104 is powered on for treatment. After powering on, DCM 102A-3 broadcasts (via configuration file manager 330) an awake message 502 over the proprietary communications network 400. The awake message 502 may include an identifier for DCM 102A-3. The awake message 502 may also include a request for an acknowledgment message. In another example, DCMs 102A-1 and 102A-2 are configured (via configuration file manager 330) to automatically send a response message 504 in response to the awake message 502. The response message 504 may include a destination and / or identifier for each DCM 102A-1 and 102A-2. This initial handshake provides DCM 102 with an indication of which other DCMs are within wireless communication range of each other.

[0155] The exemplary DCM 102A-3 may then send a registration message 506 to each of the DCMs 102A-1 and 102A-2 individually using the identifier or address provided in the response message 504. In another example, the DCM 102A-3 may broadcast the registration message 506. The registration message 506 includes the address and / or identifier of the DCM 102A-3. The registration message 506 may also include network authentication information, which ensures that only DCMs (or medical devices) from a particular manufacturer can form or connect to the proprietary communications network 400. The registration information 506 further includes date / time information (via the log manager 334) indicating when the DCM 102A-3 was powered on or activated.

[0156] DCMs 102A-1 and 102A-2 authenticate DCM 102A-3 as needed and record the registration information in their respective configuration files 332. DCMs 102A-1 and 102A-2 may also retransmit the registration information to other DCMs in network 400 to ensure that any out-of-range DCMs receive the registration information. If registration is successful, DCMs 102A-1 and 102A-2 (including any out-of-range DCMs) each send a registration response message 508. An exemplary message 508 indicates that registration was successful and that DCM 102A-3 is now part of network 400. Response message 508 may also include other information in each respective configuration file 332, such as the date / time that each DCM 102A-1 and 102A-2 was turned on, and / or the activation times of other DCMs, settings of medical network 106, etc.

[0157] FIG. 6 illustrates at least a portion of the configuration file 332 after DCM 102A-3 has been registered, according to one embodiment of the present disclosure. The configuration file 332 indicates the date / time each DCM was activated, turned on, or otherwise powered. It should be understood that each DCM 102 includes the portion of the configuration file 332 illustrated in FIG. 6. This allows the DCMs 102 to independently determine their node gateways based on protocol rules without relying on a master DCM. In the illustrated embodiment, DCM 102A-1 has the earliest date / time and is designated as the node gateway by each of the DCMs 102, as shown in FIG. 4.

[0158] Returning to FIG. 5, after registration, DCMs 102 periodically (e.g., every 1 second, 5 seconds, 10 seconds, 30 seconds, 1 minute, etc.) broadcast heartbeat messages 510 (for simplicity, the heartbeat message from DCM 102A-1 is not shown). The heartbeat messages 510 may include the DCM's identifier and indicate that the DCM 102 is still an active node on network 400. If a heartbeat message is not received by DCM 102 within a specified time limit, DCM 102 may broadcast a ping message for the missing DCM or otherwise designate the missing DCM as disconnected (by removing its date / time activation information). It should be understood that the communications described in connection with FIG. 5 occur via each DCM's 102's proprietary network interface 312.

[0159] FIG. 5 also shows that DCMs 102A-2 and 102A-3 transmit their medical device data 303 to DCM 102A-1 because DCM 102A-1 is a node gateway. DCM 102A-1 then transmits the received medical device data 303 in bulk (via medical network interface 310) to the EMR server 108. In some embodiments, DCM 102 may coordinate when snapshots of medical device data are recorded / transmitted as part of a proprietary protocol. In one example, the DCMs may record snapshots at different offsets from one another so that data transmission to node gateway DCM 102 tapers off (thereby reducing transmission bottlenecks due to network bandwidth limitations). This allows node gateway DCM 102 to spread out transmission of medical device data 303 to the EMR server 108 over time.

[0160] FIG. 7 shows a data flow diagram 700 illustrating a messaging protocol for the proprietary communication network 400 when a DCM 102 is powered off, according to an exemplary embodiment of the present disclosure. In the illustrated embodiment, the node gateway DCM 102A-1 is deactivated and / or the corresponding medical device 104 is powered off or deactivated. Before the DCM 102A-1 shuts down, it sends or broadcasts a deactivation message 702, which may include an identifier for the DCM 102A-1. The deactivation message 702 indicates that the DCM 102A-1 is going offline (and is no longer available as a node gateway). In some embodiments, the DCMs 102A-2 and 102A-3 send a response message 704 indicating that they received the deactivation message 702. The response message may also be used to replay the deactivation information to other DCMs that are not within communication range of the DCM 102A-1. DCM 102A-1 powers off after receiving at least one response message 704. Additionally, the other DCMs 102A-2 and 102A-3 update their configuration files 332 to remove the entry for DCM 102A-1 or otherwise indicate that DCM 102A-1 is not active.

[0161] Using protocol rules, the DCM 102 independently determines that DCM 102A-2 is now the node gateway. The configuration file manager 330 of DCM 102A-2 may restart its medical network interface 310 to communicate with the EMS server 108. In some embodiments, this may involve DCM 102A-2 sending an activate message to the EMR server 108 indicating that DCM 102A-2 is now the node gateway. In other examples, the handover to DCM 102A-2 is seamless because the DCMs 102 may share network settings (including the destination IP address) and can use the network settings to seamlessly communicate with the EMR server 108 instead of DCM 102A-1. In some examples, DCM 102A-2 may send a confirmation message to the other DCM 102A-3 via the proprietary network interface 312, indicating that DCM 102A-2 is available as a node gateway. At this point, the DCM 102 broadcasts heartbeat messages 510 at regular intervals. For data transmission, the DCM 102A-3 transmits medical device data 303 to the DCM 102A-2. The DCM 102A-2 then transmits the received medical device data 303 and its own medical device data 303 to the EMR server 108 at designated times (or snapshot intervals). IV. Exemplary Disposable / Consumable Tracking Embodiments

[0162] As mentioned above, hosting the proprietary communications network 400 via the DCM 102 allows functionality to be implemented that may not be supported by the medical network 106 and / or EMR server 108. Figure 8 shows a diagram of an embodiment in which the proprietary communications network 400 is used to track medical device usage of disposable or consumable items in a medical facility or patient home 800, according to an exemplary embodiment of the present disclosure.

[0163] In some embodiments, the log manager 334 of the DCM 102 is configured to analyze the medical device data 303 for disposable / consumable information. The log manager 334 maintains log files in the database 324 that track disposable / consumable usage. The log manager 334 may track the use and / or replacement of filters, cassettes, line sets, dialysis solution, saline, renal replacement solution, warmer bags, and / or disposable sensors. The medical device 104 may include usage information as event information included in the medical device data. For example, the medical device may detect or determine each time a solution bag is changed, each time a sensor is changed, etc. In some examples, some consumable / disposable items may be changed after each treatment or after a specified number of treatments.

[0164] The DCMs 102 may communicate these consumable / disposable usage information to each other. In this configuration, each DCM 102 maintains a fleet aggregate for all medical devices that are part of the network 400. The node gateway DCM 102 may periodically send messages via the medical network 106 to the EMR server 108 or hospital inventory management server, which reorders consumables / disposables as estimated quantities decrease. Thus, if a node gateway DCM 102 goes offline, the next DCM 102 also maintains the fleet aggregate. In other embodiments, only a designated DCM, such as the node gateway DCM 102, maintains the fleet aggregate count.

[0165] In some embodiments, the DCM 102 is configured to manage inventory replenishment via the configuration file manager 330. In these embodiments, the DCM 102 receives an indication of available inventory. The indication may be entered into at least one of the medical devices or may be received from a server via the medical network interface 310. In some examples, the medical network interface 310 may be configured to communicate with a wide area network, such as the Internet, to provide inventory tracking with suppliers.

[0166] As shown in FIG. 8 , the DCM 102 tracks consumable / disposable usage for each individual medical device. For example, DCM 102A-1 determines that its corresponding CRRT1 has consumed two M100 filter sets, five dialysis solution bags, and two replacement solution bags. The DCMs use a proprietary communications network 400 to share and aggregate disposable / consumable usage. The node gateway DCM 102 compares the aggregated results with an auto-generation limit to determine when a replenishment message should be generated. In some embodiments, the node gateways and / or all of the DCMs 102 may track consumption rates to estimate when inventory will fall below a threshold and generate replenishment messages accordingly. V. Exemplary Patient Fluid Management Embodiments

[0167] In some embodiments, multiple medical devices 104 on the same proprietary communications network 400 (hosted by respective DCMs 102) may communicate with each other to facilitate medical procedures. In one example, an infusion pump and a dialysis machine may communicate for fluid management. Figure 9 shows a diagram of the proprietary communications network 400 of Figure 4 configured for patient fluid management, according to an exemplary embodiment of the present disclosure.

[0168] In the illustrated embodiment, the DCM 102A-0 of the CRRT medical device 104A-0 is part of a proprietary communication network 400 with three infusion pump medical devices 104A-1 through 104A-3 and corresponding DCMs 102A-1 through 102A-3. FIG. 9 omits other medical devices that may be part of the proprietary communication network 400. The illustrated DCMs 102 determine, via their respective configuration file managers 330, that they are each assigned to the same patient. In one example, the medical devices 104 are programmed with a patient identifier as part of treatment setup. Before treatment begins, the DCM 102 receives the patient identifier identified by the log manager 334. The DCM 102 may then broadcast the patient identifier and corresponding device address and / or identifier to determine which other DCMs are associated with the same treatment. DCMs that are part of the same treatment may share medical device data 303 with each other to facilitate treatment management provided by the medical device manager 336.

[0169] In the illustrated example, a clinician uses the control interface 105 of the CRRT medical device 104A-0 to input or program the adaptive patient fluid removal, including a fluid removal volume parameter and a removal duration parameter (e.g., 1000 ml of fluid removed over 24 hours). The medical device manager 336 calculates the corresponding fluid removal rate and transmits this data to the CRRT medical device 104A-0.

[0170] During treatment, each DCM 102A-1 through 102A-3 receives medical device data 303 from a respective injection pump medical device 104A-1 through 104A-3. The medical device data 303 includes infusion rates, which are transmitted by the DCMs 102A-1 through 102A-3 to the DCM 102A-0 over the proprietary communications network 400. The infusion pump medical device 104A-1 may infuse a first fluid at a rate of 10 ml / h, the infusion pump medical device 104A-2 may infuse a third fluid at a rate of 20 ml / h, and the infusion pump medical device 104A-3 may infuse a third fluid at a rate of 25 ml / h.

[0171] The medical device data may be broadcast under protocol rules, e.g., with a sending DCM identifier so that the DCM 102A-0 determines that the broadcast transmission is intended for its mailbox 340. In another example, the DCMs 102A-1 through 102A-3 may send messages with the destination address or identifier of the DCM 102A-0 to ensure that only the DCM 102A-0 processes the received data. The medical device manager 336 of the DCM 102A-0 receives the infusion rate, combines the infusion rate with the dialysis fill rate of the CRRT medical device 104A-0, and determines a new target volume removal rate to meet the specified parameters. The medical device manager 336 sends the new fluid removal rate to the CRRT medical device 104A-0, which may be displayed by the control interface 105 as a recommendation or as a control command to the therapy module 107 to modify the prescribed treatment. It should be appreciated that such a configuration eliminates the need for a clinician to manually calculate fluid removal rates based on medical device data from multiple medical devices. The above-described configuration also allows for near real-time adjustment of the liquid removal rate to reflect any changes in the injection rate.

[0172] FIG. 10 is a flow diagram of an exemplary procedure 1000 for calculating a liquid removal rate using the proprietary communications network 400 of FIG. 4 , according to an exemplary embodiment of the present disclosure. While procedure 1000 is described with reference to the flow diagram shown in FIG. 10 , it should be understood that many other ways of performing the steps associated with procedure 1000 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. In one embodiment, the number of blocks may be varied. Additionally, the steps of updating infusion pump medical devices 104A-1 through 104A-3 and providing a notification message to a clinician may be omitted. The operations described in procedure 1000 may be specified by one or more instructions and executed among multiple devices, including, for example, DCM 102A-0 and / or medical device 104A-0.

[0173] The exemplary procedure 1000 begins when the DCM 102A-0 receives (via the event medical device data 303) an indication that a clinician has selected a fluid removal volume parameter and a removal duration parameter (among other parameters) for a CRRT treatment (block 1002). The DCM 102A-0 also receives an indication that the clinician has selected an adaptive fluid removal function (block 1004). The selection of the adaptive fluid removal function also causes the DCM 102A-0 to send a broadcast message with its own identifier and / or address to determine other medical devices associated with the same patient (block 1006). In response to the broadcast message, the DCMs 102A-1 through 102A-3 of the infusion pump medical devices 104A-1 through 104A-3 send response messages indicating the same patient identifier and / or medical device type. In some examples, after receiving the response message, DCM 102A-0 sends or broadcasts a message intended for DCMs 102A-1 through 102A-3 requesting that infusion rate medical device data 303 be sent. In other embodiments, the initial broadcast message may identify the medical device data that is required.

[0174] As shown in FIG. 10, the DCMs 102A-1 through 102A-3 send messages containing infusion rate medical device data 303 along with the destination address and / or identifier of the DCM 102A-0 (block 1008). The DCM 102A-0 receives the data 303 and sums it with the dialysis fill rate included in the medical device data 303 from the CRRT medical device 104A-0 to determine the total rate of fluid being provided to the patient (block 1010). The DCM 102A-0 then compares the total fluid rate with adaptive fluid parameters to ensure that the fluid removal volume is met by the specified time period (block 1012). The DCM 102A-0 uses the comparison results to determine whether adjustments are needed to the infusion and / or CRRT treatment (block 1014). This determination may be made by the medical device manager 336 of the DCM 102A-0 determining whether the fluid removal trend meets the desired removal rate.

[0175] If no adjustment is needed, the DCM 102A-0 returns to block 1008 and subsequent medical device data 303 is received (e.g., the next snapshot of data). If adjustment is needed, the medical device manager 336 of the DCM 102A-0 determines a new fluid removal rate for the CRRT medical device 104A-0 to meet the fluid volume and time parameters (block 1016). The DCM 102A-0 then sends a message 1017 to the CRRT medical device 104A-1 indicating the new fluid removal rate. In some embodiments, the CRRT medical device 104A-1 displays the removal rate as a treatment recommendation on the control interface 105. In other embodiments, the CRRT medical device 104A-1 routes the message 1017 to the therapy module 107 to update the CRRT treatment with the new fluid removal rate.

[0176] In some embodiments, the DCM 102A-0 may determine an adjustment to one or more of the infusion rates (block 1018). In these embodiments, the DCM 102A-0 sends a message 1019 directed to the appropriate DCM 102A-1-102A-3 with the revised infusion rate. Similarly, the designated DCM 102A-1-102A-3 displays a recommendation or change of treatment.

[0177] Additionally, in some embodiments, the notification processor 316 may generate a notification message 1021 indicating a fluid removal rate change / recommendation and / or an infusion pump infusion rate change / recommendation (block 1020). The DCM 102A-1 transmits the notification message 1021 to the designated clinician device 322 via the network 400 and / or to a separate wireless communication link via the clinician device interface 314. The example procedure 1000 of FIG. 10 continues by returning to block 1008 for a subsequent snapshot (or stream) of medical device data 303. VI. Embodiments of Clinician Decision Support

[0178] In some embodiments, the DCM 102 (medical device manager 336) is configured to analyze medical device data 303 from connected medical devices 104 in combination with medical device data and / or laboratory results from devices outside the proprietary communications network. Instead, medical device data from these other devices is stored in the patient's EMR via the EMR server 108 and is available only via the medical network 106. Figure 11 shows a diagram of an embodiment of clinician decision support in which the DCM 102 is configured to provide decision support to connected medical devices 104 using, in part, medical device data received from the EMR server 108, according to an exemplary embodiment of the present disclosure.

[0179] FIG. 11 shows a diagram of the DCM 102 of FIGS. 1-3 configured to provide clinician decision support, according to an exemplary embodiment of the present disclosure. In the illustrated example, DCMs 102A-1 and 102A-2 are associated with CRRT medical devices 104A-1 and 104A-2. Each of the DCMs 102A-1 and 102A-2 (e.g., individual medical network interfaces 310) is connected to an EMR server 108 via a medical network 106. Further, the EMR server 108 is communicatively coupled to a blood pressure monitor 1102, a blood gas analyzer 1104, an infusion delivery system 1106, and other devices 1108 via the medical network 106. The other devices may include a laboratory server providing laboratory results, a pharmacy server providing prescribed medications, a weight scale, a thermometer, a heart rate monitor, etc.

[0180] In the illustrated embodiment, the medical device managers 336 of the DCMs 102A-1 and 102A-2 are configured for bidirectional communication with the EMR server 108. To receive data from the EMR server 108, the medical device managers 336 may determine the patient identifier of the patient connected to or associated with the corresponding CRRT medical device 104. The medical device managers 336 send a request message to the EMR server 108 via the medical network interface 310. The request message includes the patient identifier and the identifier and / or network address of the DCM 102.

[0181] The EMR server 108 identifies the patient's EMR record and identifies the requested data. The EMR server 108 then transmits the identified data to the mailbox 340 of the requesting DCM 102. In some examples, a request from the DCM 102 causes the EMR server 108 to provide a stream of data as it is received from the associated devices 1102-1108 for a specified duration and / or procedure.

[0182] The example medical device manager 336 of the DCM 102 is configured to combine data received from the EMR server 108 with medical device data 303 received from individual medical devices 104. The medical device manager 336 may then apply one or more rules or criteria to the combined data.

[0183] In some embodiments, one or more rules or criteria may specify that certain of the received data should be displayed on the medical device 104. In response, the medical device manager 336 sends the specified data to the therapy module 107 for display on the control interface 105 of the medical device 104. In other examples, the medical device manager 336 may store the specified data in a mailbox 340. In these other examples, the therapy module 107 may periodically poll the mailbox 340 for data to be displayed. In some examples, the medical device manager 336 may identify a treatment recommendation or adjustment, and information indicative of the recommendation or adjustment is stored in the mailbox 340 and / or sent to the medical device 104 for display. In further embodiments, the medical device manager 336 may determine parameter and / or treatment adjustments based on a comparison with the rules and / or criteria. In these embodiments, the medical device manager 336 sends new parameter or adjustment information to the mailbox 340 or the therapy module 107 to modify an ongoing or subsequent therapy provided by the medical device 104.

[0184] In one example, the DCM 102 may receive blood pressure data from the EMR server 108 during a CRRT treatment. In response, the DCM 102 may determine that the dwell or drain phase of the CRRT treatment should be extended based on one or more rules and / or criteria stored in the database 324. The DCM 102 may send a recommendation to increase the dwell or drain phase or may increase the dwell or drain phase duration to the CRRT medical device 104.

[0185] It should be appreciated that the DCM 102, in one embodiment, is an edge computing node within the medical network 106. For proprietary communication networks, multiple DCMs 102 for edge computing nodes allow at least some clinical decision making to occur at the edge of the medical network 106 rather than at a centralized location such as the EMR server 108. Such a configuration may reduce computational resources at the EMR server 108 and prevent processing bottlenecks that may be common from centralized clinical support. VII. Clinician Event Notification Embodiments

[0186] As mentioned above, the DCM 102 of FIGS. 1-3 includes a notification processor 316 for generating notification messages for clinician devices 322. FIG. 12 shows an exemplary diagram of how the proprietary communication network 400 of FIG. 4 is used to provide notification messages to clinician devices 322, according to an exemplary embodiment of the present disclosure. In the illustrated embodiment, the DCM 102 of the medical device 104 is configured to send notification messages to registered clinician devices 322. In instances where the clinician devices 322 are able to interact with the proprietary communication network 400 (e.g., via a Bluetooth transceiver), the DCM 102 is configured to use these proprietary network interfaces 312. In instances where a separate connection to the clinician devices 322 is required, the DCM 102 is configured to use the clinician device interface 314.

[0187] The configuration shown in FIG. 12 allows the clinician device 322 to receive notifications about the status of connected medical devices 104 without the need for the clinician to be in close proximity to the medical device. The status may include alarms, alerts, and / or events. Remote access of medical devices may be important when clinician presence at a patient's bedside for an extended period of time is not feasible, such as for the treatment of highly infectious diseases like COVID-19. Furthermore, as shown in FIG. 12, a single clinician device 322 may be used to simultaneously monitor, for example, nine different medical devices 102.

[0188] It should be appreciated that the disclosed embodiments enable personal mobile devices to receive medical notifications even if the medical network 106 does not have such capabilities. Thus, medical device manufacturers may provide remote monitoring and control of clinician devices 322 without affecting the medical network 106. Such a configuration provides another layer of security because the clinician device 322 does not need to connect to the medical network 106 for configuration or to receive notifications, thereby eliminating a potential security entry point into the network. Furthermore, access to the network 400 and / or DCM 102 is local, preventing remote malicious applications from even reaching the network 400 or associated medical devices.

[0189] During the enrollment phase (described below), the clinician accesses DCM 102 to complete a template form regarding which notifications are desired, including setting thresholds and / or conditions regarding when notifications should be generated. For example, the clinician may complete a form to receive pressure alarms, empty bag alarms, filter clot alarms, unused bag low alerts, etc. The form may also allow the clinician to prioritize when and / or which notifications are provided.

[0190] The example notification processor 316 of the DCM 102 compares the medical device data 303 with criteria specified by the clinician. If at least one of the criteria is met, the notification processor 316 creates a notification message (e.g., a text or SMS message or a push notification) that is sent to the clinician device 322 via the clinician device interface 314 and / or the proprietary network interface 312. In some examples, the clinician device 322 may be out of wireless range of at least one of the monitored medical devices 104. To address such issues, the DCM of the proprietary communications network 400 is configured to broadcast and rebroadcast notification messages to ensure the messages reach the clinician device 322. The network 400 may have protocol rules regarding the number of times notifications are rebroadcast. Additionally, in some embodiments, the clinician device 322 may provide an acknowledgment message when a notification message is received, prompting the DCM 102 to stop broadcasting notifications.

[0191] FIG. 13 shows a diagram of how the DCM 102 is configured for sending notification messages to the clinician device 322 of FIG. 12 , according to an exemplary embodiment of the present disclosure. In the illustrated embodiment, the computer 1300 includes an application 1302 that allows a clinician to access and edit forms on a designated DCM 102. The computer 1300 may access the DCM 102 via the medical network interface 310 through the medical network 106. In this example, the application 1302 may include fields for an identifier or network address of the DCM 102 and / or medical device 104. Entering the identifier or address causes the application 1302 to access the DCM 102 or send a request message for a notification form. After receiving the form, the application 1302 displays fields for input by the clinician regarding criteria and / or conditions for receiving notifications. The clinician may also provide an identifier for their clinician device 322 to subscribe to designated notifications.

[0192] In other embodiments, the application 1302 may further include fields corresponding to a form in the DCM 102. The clinician completes the fields, including the DCM / medical device identifier, criteria / conditions, and destination device. After completing the fields, the clinician causes the application 1302 to send one or more messages with the data from the fields to, for example, an API in the notification processor 316 of the desired DCM 102 to store the received information in a notification record stored in the database 324 (or broadcast the information, with only the designated DCM 102 processing the request).

[0193] In some embodiments, the application 1302 may also configure the clinician device 322. For example, the application 1302 may provide instructions for pairing the clinician device 322 with the proprietary communications network 400 and / or the designated DCM 102. In other examples, the application 1302 causes a notification message to be sent to the clinician device 322. The notification message includes a link to a script that, when selected on the clinician device 322, automatically configures the device 322 to connect to the network 400 and / or the designated DCM 102. Once configured, the clinician device 322 can receive notification messages from the DCM 102 regarding events, alarms, and / or alerts related to the corresponding medical device 104.

[0194] The notification functionality described above provides benefits to clinicians for CRRT medical devices. Typically, a CRRT medical device has a specific number of unused dialysate bags and a specific number of drain bags. Rather than having the clinician periodically check the status of the bags, the DCM 102 uses specified criteria for sending a notification when an unused bag is nearly empty (e.g., within 15 to 20 minutes of being empty). The DCM 102 also uses specified criteria for sending a notification when a drain bag is nearly full. Thus, the DCM 102 provides clinician notifications via the device 322 only when attention is required for a particular medical device, even if the medical network does not necessarily support clinician-device connectivity. VIII. conclusion

[0195] 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 healthcare system comprising: at least one medical device (104), one or more sensors and one or more actuators; - Memory and a processor (107) configured to receive data from the one or more sensors and to control the one or more actuators to perform a medical task, a processor (107) that can access the memory and is configured to store data including medical device data (303); a communications unit connected to the processor (107), the communications unit including at least one of a serial input port, an Ethernet input port, and a wireless input port; At least one medical device (104) including: at least one digital communication module (102) associated with said medical device (104), said at least one digital communication module (102) comprising: an input interface (304) communicatively coupled to the communication unit of the medical device (104), the input interface (304) including at least one of a serial input port, an Ethernet input port, and a wireless input port; an output interface (306) configured for communicative coupling with (i) an electronic medical record (EMR) server (108) via a medical network (106) and (ii) at least one other digital communication module (102A) via a wireless network (400) that is separate from the medical network (106), the output interface (306) including at least one of a serial output port, an Ethernet output port, and a wireless output port; a file configuration manager (330) configured to store at least one configuration file (332) together with an identifier of said at least one digital communication module (102); a data manager (302) communicatively coupled to said input interface (304), said output interface (306) and said file structure manager (330), said data manager (302) comprising: sending an awake message to the at least one other digital communication module (102A) over the wireless network (400) after being powered on, the awake message including the identifier of the at least one digital communication module (102) and a date / time indication of the power-on; receiving a response message from each of the at least one other digital communication module (102A) via the wireless network (400), the response message including an identifier or network address of the respective other digital communication module (102A) and a date / time indication of when the respective other digital communication module (102A) was powered on; receiving medical device data (303) from said medical device (104); determining that the medical device data (303) should be transmitted to the EMR server (108) via a first digital communication module (102) having an earliest date / time indication among the at least one other digital communication module (102A); transmitting the medical device data (303) to the first digital communication module (102) for transmission to the EMR server (108); a data manager (302) configured to: and at least one digital communication module (102) comprising:

2. A digital communication module (102), an input interface (304) configured for communicatively coupling to a medical device (104), said input interface (304) including at least one of a serial input port, an Ethernet input port, and a wireless input port; an output interface (306) configured for communicative coupling with (i) an electronic medical record (EMR) server (108) via a medical network (106), and (ii) at least one other digital communication module (102A) via a wireless network (400) that is separate from said medical network (106), said output interface (306) including at least one of a serial output port, an Ethernet output port, and a wireless output port; a file configuration manager (330) adapted to store at least one configuration file (332) together with an identifier of said digital communication module (102); a data manager (302) communicatively coupled to said input interface (304), said output interface (306) and said file structure manager (330), said data manager (302) comprising: sending an awake message to the at least one other digital communication module (102A) over the wireless network (400) after being powered on, the awake message including the identifier of the digital communication module (102) and a date / time indication of the power-on; receiving a response message from each of the at least one other digital communication module (102A) via the wireless network (400), the response message including an identifier or network address of the respective other digital communication module (102A) and a date / time indication of when the respective other digital communication module (102A) was powered on; receiving medical device data (303) from said medical device (104); determining that the medical device data (303) should be transmitted to the EMR server (108) via a first digital communication module of the at least one other digital communication module (102A) having an earliest date / time indication; transmitting the medical device data (303) to the first digital communication module (102) for transmission to the EMR server (108); a data manager (302) configured to: A digital communication module (102) comprising:

3. The data manager (302) receiving a power-off message from a first digital communication module (102) indicating that the first digital communication module (102) is no longer available; removing the date / time indication of the first digital communication module (102); receiving second medical device data (303) from the medical device (104); determining that the second medical device data (303) should be transmitted to the EMR server via a second digital communication module (102) among the at least one other digital communication module (102A) having an earliest date / time indication by removing the date / time indication of the first digital communication module (102); transmitting the second medical device data (303) to the second digital communication module (102) for transmission to the EMR server (108); The medical system of claim 1 or the module of claim 2, further configured to:

4. The data manager (302) receiving a power-off message from the first digital communication module (102) indicating that the first digital communication module (102) is no longer available; removing the date / time indication of the first digital communication module (102); receiving second medical device data (303) from the medical device (104); determining that the second medical device data (303) should be transmitted to the EMR server (108) via the digital communication module (102) based on the digital communication module (102) having the earliest date / time indication among the at least one other digital communication module (102A); transmitting the second medical device data (303) to the EMR server (108) via the communication coupling of the output interface (306) to the medical network (106); 4. The medical system or module of claim 1, further configured to:

5. The data manager (302) receiving third medical device data (303) from one of the at least one other digital communication module (102A); transmitting the third medical device data (303) to the EMR server (108) via the communication coupling of the output interface (306) to the medical network (106); The medical system or module of claim 4 further configured to:

6. The data manager (302) designating the new first digital communication module (102) as a node gateway for transmission of said medical device data (303); designating the new first digital communication module (102) as the node gateway after receiving the power-off message from the first digital communication module (102) and determining that the new first digital communication module (102) has the earliest date / time indication among the at least one other digital communication module (102A); 6. The medical system or module of claim 4 or 5, further configured to:

7. the processor (107) monitors treatment delivery through the medical device; - the type and number of single-use disposables that have been used and must be replaced to perform subsequent procedures; and / or The type and number of semi-disposable elements that are used up or must be replaced, and / or - the type and number of failed components that must be replaced; configured to determine first disposable or consumable item usage information including: the processor (107) stores the first disposable or consumable item usage information in the memory, and the first disposable or consumable item usage information is transferred to the digital communication module (102) through the communication unit; The data manager (302) receiving first disposable or consumable usage information from the medical device; receiving second disposable or consumable item usage information from the at least one other digital communication module (102A); combining the first and second disposable or consumable item usage information; transmitting the combined first and second disposable or consumable item usage information to at least one of the EMR server (108) and a medical supply server via the communication coupling of the output interface (306) to the medical network (106); 7. The medical system or module of claim 4, further configured to:

8. 8. The medical system or module of claim 7, wherein the first and second disposable or consumable usage information includes information indicating usage of a filter, a disposable cassette, a line set, a dialysis solution, saline, a renal replacement solution, a warmer bag, or a disposable sensor.

9. 9. The medical system or module of claim 1, wherein the configuration file (332) specifies a destination network address of the EMR server (108), an identification of the medical device (104) type of the communicatively coupled medical device (104), an identification of the medical device (104) serial number, and a timestamp when the received medical data was generated by the medical device (104) or received by the data manager (302) from the medical device (104).

10. The data manager (302) - receiving a stream of said medical device data (303); - creating snapshots of said medical device data (303) at regular intervals; providing said snapshot of said medical device data (303) as said medical device data (303) transmitted to said first digital communication module (102); further configured to: The medical device data (303) includes: event information including transitions between fill, dwell, and drain phases of a dialysis cycle; alarm, alert, or event information; treatment programming information; medical procedure data including at least one of an estimated fill rate, a drain rate, and an amount of ultrafiltration removed; 10. A medical system or module according to any one of claims 1 to 9, comprising at least one of:

11. The data manager (302) using event tracking to identify changes to said medical device data (303) between snapshots; including only the changed medical device data (303) from a previous snapshot as the medical device data (303) transmitted to the first digital communication module (102); 11. The medical system or module of claim 1, further configured to:

12. The data manager (302) receiving a configuration message via the output interface (306), the configuration message indicating a network address of a clinician device and criteria for sending notifications to the clinician device; determining that at least a portion of the medical device data (303) meets the criteria; sending a notification message to the clinician device over the wireless network indicating the at least a portion of the medical device data that meets the criteria; 12. The medical system or module of claim 1, further configured to:

13. and further including at least one other medical device that is an infusion pump, wherein the medical device (104) is a dialysis machine; the at least one other digital communication module (102A) is associated with each of the infusion pumps; the medical device data (303) from the dialysis machine includes a patient identifier, and the second medical device data (303) from the at least one infusion pump includes the same patient identifier and an infusion rate; The data manager (302) receiving an indication that adaptive liquid removal operation is enabled; - the flow rate of unused dialysate entering the filtration unit; - the output flow rate leaving the filtration unit; - pre-infusion flow rate into the extracorporeal blood circuit; - post-infusion flow rate into the extracorporeal blood circuit; - A target amount of liquid to be removed and a removal period; - liquid removal rate; receiving parameter data associated with the patient identifier, the parameter data including one or more of: receiving the second medical device data (303) from the at least one other digital communication module (102A) via the wireless network (400); determining whether the at least one infusion pump is associated with the same patient identifier; determining an amount of fluid being infused into the patient or an infusion rate based on the second medical device data (303); determining updated parameter data based on the amount of fluid being infused into the patient or the infusion rate determined from the parameter data and the second medical device data (303); transmitting the updated parameter data to the dialysis machine via the input interface (304); 13. The medical system or module of any one of claims 1 to 12, further configured to:

14. The data manager (302) - Either the target amount of liquid removal and the removal period, or - a fluid removal rate of a patient associated with said patient identifier; receiving parameter data associated with the patient identifier, The updated parameter data includes: i) the liquid removal target amount and the removal period, or the liquid removal rate; ii) the amount of fluid being infused into the patient or the infusion rate; and at least one updated flow rate for the dialysis machine based on transmitting the at least one updated flow rate to the dialysis machine via the input interface (304); 14. The medical system or module of claim 13, further configured to:

15. 15. The medical system or module of claim 14, wherein the transmission of the updated flow rate causes the dialysis machine to display a recommendation on a screen indicating the updated flow rate or to update a programmed treatment based on the updated flow rate.

16. 16. The medical system or module of claim 14 or 15, wherein determining the at least one updated flow rate includes recalculating one or more flow rates for the dialysis machine to maintain a consistent patient fluid balance, the one or more flow rates including one or more of: a fresh dialysate flow rate entering a filtration unit; an output flow rate leaving the filtration unit; a pre-infusion flow rate into an extracorporeal blood circuit; a post-infusion flow rate into the extracorporeal blood circuit; and a fluid removal rate.

17. The data manager (302) receiving sensor data from the EMR server (108) via the medical network (106); transmitting the sensor data to the medical device (104) via the input interface (304) for display on a screen of the medical device (104); comparing the sensor data and at least a portion of the medical device data (303) to stored criteria; transmitting at least one recommendation message to the medical device via the input interface, the recommendation message causing the screen to display information indicative of the comparison; 17. The medical system or module of any one of claims 1 to 16, further configured to:

18. - further comprising a plurality of medical devices (104) and a plurality of digital communication modules (102A-0, ..., 102A-6), each of said plurality of medical devices (104) being associated with one respective digital communication module (102) of said plurality of digital communication modules (102A-0, ..., 102A-6); 18. The medical system of claim 1, wherein the plurality of digital communication modules (102A-0, ..., 102A-6) are configured to designate one digital communication module (102) as a node gateway that exclusively connects to the medical network (106).

19. the medical device (104) is a medical fluid delivery machine, and the one or more actuators include one or more pumps; The medical device (104) comprises: a filtration unit having a primary chamber and a secondary chamber separated by a semipermeable membrane; a blood circuit, a blood removal line extending between a first end connected to the inlet of the primary chamber and a second end for connection to a patient; a blood return line extending between a first end connected to the outlet of the primary chamber and a second end for connection to the patient; a blood circuit including: a blood pump for circulating blood through said blood circuit; a dialysate line connected to the outlet of said secondary chamber; 19. The medical system according to any one of claims 1 and 3 to 18, which is an apparatus for the treatment of renal diseases involving extracorporeal circulation of blood, comprising:

20. further comprising a medical network and electronic medical record (EMR) server (108); 20. The medical system of any one of claims 1 and 3 to 19, wherein the medical network (106) includes at least one of a Wi-Fi network and an Ethernet network, and the digital communication module (102) transmits the medical device data (303) to the medical network for inclusion in the EMR server (108).

21. A digital communication module (102), an input interface (304) configured for communicative coupling to a medical device (104), said input interface (304) including at least one of a serial input port, an Ethernet input port, and a wireless input port; an output interface (306) configured for communicative coupling with (i) at least one other digital communication module (102A) via a wireless network (400), and (ii) a clinician device (322) via the wireless network or a direct wireless link, the output interface (306) including at least one of an Ethernet output port and a wireless output port; a memory device (112) configured to store at least one configuration file (332) with network addresses or identifiers of clinician devices (322) and criteria for sending notifications to said clinician devices; a data manager (302) communicatively coupled to the input interface (304), the output interface (306) and the memory device (112), the data manager (302) comprising: receiving medical device data (303) from said medical device (104); determining that at least a portion of the medical device data meets the criteria; sending a notification message to the clinician device via the wireless network or the direct wireless link, the notification message indicating the at least some of the medical device data that meets the criteria; a data manager (302) configured to: The digital communication module (102) is configured to broadcast and rebroadcast the notification message to ensure that the notification message reaches the clinician device (322), and the data manager (302) is configured to rebroadcast the notification message until one of the following conditions is met: a maximum broadcast time is reached, a maximum number of broadcasts have been made, or an acknowledgement message for the notification message is received from the clinician device (322).

22. The data manager (302) - allowing authorized connections from the clinician device (322); - providing a template form requesting data regarding which notifications are desired and including set thresholds and / or conditions regarding when said notifications should be generated; - using template form data to set said criteria; 22. The digital communication module (102) of claim 21, further configured to:

23. the wireless network (400) includes at least one of a Zigbee® wireless protocol, a Z-Wave® wireless protocol, a WeMo® wireless protocol, and a Low Power Wide Area Network (“LPWAN”) wireless protocol; 23. The digital communication module (102) of claim 21 or 22, wherein the direct wireless link is provided using at least one of a Bluetooth® wireless protocol, a Bluetooth® mesh wireless protocol, and a Bluetooth® 5.0 wireless protocol.

24. 24. The digital communication module (102) of any one of claims 21 to 23, wherein the direct wireless link is included as part of the wireless network (400).

25. 25. The digital communication module (102) of any one of claims 21 to 24, wherein the criteria for the notification correspond to at least one of an alarm, an alert, and an event.

26. 1. A method for transferring medical device data (303) from at least one medical device (104) to an EMR server (108) through at least one digital communication module (102), comprising: The medical device (104) comprises: one or more sensors and one or more actuators; - Memory and a processor (107) configured to receive data from the one or more sensors and to control the one or more actuators to perform a medical task, a processor (107) that can access the memory and is configured to store data including medical device data (303); a communications unit connected to the processor (107), the communications unit including at least one of a serial input port, an Ethernet input port, and a wireless input port; The at least one digital communication module (102) an input interface (304) communicatively coupled to the communication unit of the medical device (104), the input interface (304) including at least one of a serial input port, an Ethernet input port, and a wireless input port; an output interface (306) configured for communicative coupling with (i) an electronic medical record (EMR) server (108) via a medical network (106) and (ii) at least one other digital communication module (102A) via a wireless network (400) that is separate from the medical network (106), the output interface (306) including at least one of a serial output port, an Ethernet output port, and a wireless output port; a file configuration manager (330) configured to store at least one configuration file (332) together with an identifier of said at least one digital communication module (102); a data manager (302) communicatively coupled to said input interface (304), said output interface (306) and said file structure manager (330); The method comprises: coupling the at least one digital communication module (102) to the medical device (104); coupling said at least one digital communication module (102) to said EMR server (108); After being powered on, sending an awake message via the data manager (302) to the at least one other digital communication module (102A) over the wireless network (400), the awake message including the identifier of the at least one digital communication module (102) and a date / time indication of the power-on; receiving a response message from each of the at least one other digital communication module (102A) via the wireless network (400), the response message including an identifier or network address of the respective other digital communication module (102A) and a date / time indication of when the respective other digital communication module (102A) was powered on; receiving medical device data (303) from said medical device (104); determining that the medical device data (303) should be transmitted to the EMR server (108) via a first digital communication module (102) having an earliest date / time indication among the at least one other digital communication module (102A); transmitting the medical device data (303) to the first digital communication module (102) for transmission to the EMR server (108); A method comprising:

Images