Digital communication module for transmitting data from medical devices

Abstract

A digital communication module for transmitting data from a medical device is disclosed. In an example, the digital communication device includes an input interface configured for communication coupling with the medical device and an output interface configured for communication coupling with a medical network. The processor of the digital communication device receives a configuration file specifying an input port of the input interface and at least one output port of the output interface, a first data format, and a second data format. The processor installs drivers for the input port and output port specified in the configuration file, provides an input interface with the specified input port to receive medical data from the medical device according to the first data format, and provides an output interface with at least one specified output port to transmit the received medical data using the first and second data formats.

Description

Technical Field Background Technology

[0002] Healthcare networks typically have a large number of connected medical devices. The network receives data from these devices. After receiving the data, servers connected to the network store it in the patient's electronic medical record (“EMR”) or relay it to certain hospital systems such as pharmacy systems. For security reasons, the data collected from medical devices is only internally accessible to user devices authorized to connect to the healthcare network. As a result of this network security, third parties (such as medical device manufacturers) typically cannot access the data generated by the medical devices they deploy.

[0003] Some manufacturers attempt to remove at least some device data, including diagnostic information, by having sales representatives or technicians physically access each medical device. However, this is an extremely labor-intensive process. Furthermore, due to the time and cost involved in data collection, this manual process often overlooks or neglects many medical devices during data collection. This can create gaps when analyzing data later. Additionally, this manual collection method is not timely, as data may only be analyzed days, weeks, or even months after collection.

[0004] Some other medical device manufacturers have been granted limited access to medical device data stored within medical networks. In these instances, device manufacturers have access to data repositories separate from patient records and hospital systems. One problem is that the data is limited to medical data transferred from the medical device and may not necessarily include data of interest to the manufacturer, such as diagnostic or usage information. Furthermore, the data is formatted in a manner specified by the hospital system, which can make large-scale processing, handling, and analysis of the data difficult or impossible. Moreover, device manufacturers with medical devices in dozens to hundreds of different hospital systems (each with its own protocols and data storage requirements) must access each system individually and perform all data transformations to produce a unified and usable dataset.

[0005] The aforementioned problems deprive medical device manufacturers of valuable device data. For example, manufacturers can use device data to resolve device issues, identify device operational trends, treatment trends, determine device operation recommendations, or help plan the development of next-generation devices. This lack of data often leads medical device manufacturers to react to problems rather than proactively address them, which, in the long run, impacts the quality of patient care. Summary of the Invention

[0006] This document discloses a digital communication module (“DCM”) for transmitting data from a medical device. An exemplary DCM is located between the processor (or therapeutic module) of the medical device and a medical network. In some embodiments, the DCM is external to the medical device (connected via a serial connection or an Ethernet connection). In other embodiments, the DCM is included within or integrated with the medical device. The DCM disclosed herein is configured as a gateway (such as an Internet of Things (“IoT”) gateway) to transmit medical device data in parallel or simultaneously to the medical network and an external server separate from the medical network (e.g., a medical device manufacturer server using an IoT shadow service).

[0007] In this embodiment, the DCM receives medical device data from the processor or therapeutic module of the medical device. The DCM is configured to transmit two separate streams of medical device data to the medical network. For the first data stream, the DCM provides the medical device data in a first format for transmission to an external server operable by the device manufacturer of the respective medical device. For the second data stream, the DCM provides the medical device data in a second format for transmission to an EMR server or hospital system within the hospital network. In some instances, the DCM can de-identify the medical device data in the first data stream and add log / health data of interest to the device manufacturer, as well as allow for advanced analytics to evaluate the operation of the medical device. For the second data stream, the DCM transmits medical device data with patient identification information for inclusion in the appropriate EMR or for use by the appropriate hospital system. Therefore, the DCM provides medical device manufacturers with easy access to valuable medical device data in a common format for data analysis, while also providing hospital systems with medical device data in the same format previously used internally (thus eliminating the need to modify the medical network).

[0008] The exemplary DCM disclosed herein can be remotely configured via a configuration file. The exemplary file allows an operator to specify the type of medical device, the hardware interface for connecting to the medical device, the device driver for data management, the data transfer type, and the hardware interface for data transfer. Upon receiving the configuration file, the DCM is configured to install the specified drivers and configure the specified input and output interfaces for seamless integration between the medical device and the medical network. The configuration file can be updated to change connectivity requirements and / or data formats, thus providing device manufacturers with flexibility after the DCM has been deployed at a hospital site.

[0009] The exemplary DCM can operate with any type of medical device. For example, the DCM can operate with medical devices used for plasma exchange, hemodialysis (“HD”), hemofiltration (“HF”), hemodialysis filtration (“HDF”), and continuous renal replacement therapy (“CRRT”). The DCM described herein can also operate with medical devices used for peritoneal dialysis (“PD”), intravenous drug delivery, and nutritional fluid delivery. These different treatment modalities may be collectively referred to herein or generally referred to separately as medical fluid delivery or therapy.

[0010] The above-described configuration can be provided by a medical fluid delivery system, which houses the components required for delivering medical fluids, such as one or more pumps, valves, heaters (if needed), in-line medical fluid generation equipment (if needed), sensors (such as pressure sensors, conductivity sensors, temperature sensors, air detectors, blood leak detectors, etc.), a user interface, and a control unit. The control unit may employ one or more processors and memory to control the aforementioned equipment. The medical fluid delivery system may also include one or more filters, such as dialyzers or blood filters for purifying blood and / or ultrafilters for purifying water, dialysis fluid, or other fluids.

[0011] The DCM and medical fluid delivery systems described herein can be used with home machines. For example, the system can be used with home HD, HF, or HDF machines that operate at the patient's convenience. One such home system is described in U.S. Patent No. 8,029,454 (“'454 Patent”), filed November 4, 2004, entitled “High Convection Home Hemodialysis / Hemofiltration And Sorbent System”, published October 4, 2011, which has been assigned to the assignee of this application. Other such home systems are described in U.S. Patent No. 8,393,690 (“'690 Patent”), filed August 27, 2008, entitled “Enclosure for a Portable Hemodialysis System”, published March 12, 2013. The entire contents of the foregoing references are incorporated herein by reference and are based thereon.

[0012] As detailed below, the DCM of this disclosure can operate within an inclusive platform system that may include many machines (including many different types of devices), patients, clinicians, physicians, service personnel, electronic medical record (“EMR”) databases, websites, resource planning systems that process data generated through patient and clinician communications, and business intelligence. The DCM of this disclosure operates seamlessly throughout the system without violating its rules and protocols.

[0013] According to the disclosure herein, without limiting the scope of this disclosure in any way, in a first aspect of this disclosure (which may be combined with any other aspect listed herein), a digital communication device includes an input interface configured for communication coupling with a medical device and an output interface configured for communication coupling with a medical network. The input interface includes a serial input port, an Ethernet input port, and a wireless input port. The output interface includes at least one of a serial output port, an Ethernet output port, or a wireless output port. The digital communication device also includes a memory device configured to store drivers for the input ports and the output ports and at least one configuration file. The digital communication device further includes a processor communicatively coupled to the input interface, the output interface, and the memory device. The processor is configured to receive a configuration file from a management computer via the output interface, the configuration file specifying one of the input ports of the input interface and at least one output port of the output interface, a first data format, and a second data format. The processor is also configured to store a configuration file in a memory device, install drivers for input and output ports specified in the configuration file, provide a specified input port for an input interface to receive medical data from a medical device in a first data format, and provide at least one specified output port for an output interface to transmit at least a portion of the received medical data using a first data format and a second data format.

[0014] In a second aspect of this disclosure (which may be combined with any other aspect listed herein), the processor is configured to: receive medical data from a medical device in a first format via an input interface; select a first subset of the medical data via one of the output ports specified in a configuration file for transmission via the output interface in the first data format; convert a second subset of the medical data into a second data format; and transmit a second subset of the medical data in the second data format for transmission via the same or different output ports specified in the configuration file.

[0015] In the third aspect of this disclosure (which may be combined with any other aspect listed herein), the first subset of medical data is identical to the second subset of medical data.

[0016] In a fourth aspect of this disclosure (which may be combined with any other aspect listed herein), the output interface provides communication coupling with at least one of an electronic medical record (“EMR”) server, a middleware server, or an integration engine via a medical network, and the processor is configured to transmit a second subset of medical data to at least one of the EMR server, the middleware server, or the integration engine in a second data format using the same or different output ports specified in the configuration file.

[0017] In a fifth aspect of this disclosure (which may be combined with any other aspect listed herein), at least one of an Ethernet port and a wireless port provides communication coupling to a remote server outside the medical network, and the processor is configured to use at least one of the Ethernet port or the wireless port to transmit a first subset of medical data to the remote server in a first data format.

[0018] In a sixth aspect of this disclosure (which may be combined with any other aspect listed herein), the processor includes a first connectivity agent and uses a messaging protocol to transmit a first subset of medical data in a first data format.

[0019] In the seventh aspect of this disclosure (which may be combined with any other aspect listed herein), the messaging protocol includes the Message Queuing Telemetry Transport (“MQTT”) publish-subscribe network protocol.

[0020] In the eighth aspect of this disclosure (which may be combined with any other aspect listed herein), the configuration file specifies a first destination network address for receiving a first subset of medical data in a first data format and a second destination network address for receiving a second subset of medical data in a second data format, wherein the first destination network address is associated with a network domain outside the medical network and the second destination network address is associated with a network domain including the medical network.

[0021] In a ninth aspect of this disclosure (which may be combined with any other aspect listed herein), the processor is configured to: generate log data and health data; include the log data and health data in a first subset of medical data via an output port specified in a configuration file for transmission via an output interface in a first data format; convert the log data to a second data format; and include the log data in a second subset of medical data for transmission via the same or different output ports specified in the configuration file.

[0022] In the tenth aspect of this disclosure (which may be combined with any other aspect listed herein), the log data includes at least one of the following: identification of the medical device type, identification of the medical device serial number, timestamps of the received medical data generated by the medical device or received by the processor from the medical device, device identifier, timestamps of a first subset of the medical data, or monotonic timestamps, and the health information includes information related to memory devices, CPU usage information, network connectivity information, process / thread information, or information related to software operated by the processor for processing and transmitting a first and second subset of the medical data.

[0023] In the eleventh aspect of this disclosure (which may be combined with any other aspect listed herein), the processor is configured to: anonymize patient information included in a first subset of medical data prior to transmission, or encrypt a first subset of medical data prior to transmission.

[0024] In the twelfth aspect of this disclosure (which may be combined with any other aspect listed herein), the processor is configured to receive a stream of medical data, create snapshots of the medical data at periodic intervals, and provide snapshots of the medical data as at least one of a first subset or a second subset of the medical data.

[0025] In the thirteenth aspect of this disclosure (which may be combined with any other aspect listed herein), the periodic interval has a period between 5 seconds and 60 seconds.

[0026] In the fourteenth aspect of this disclosure (which may be combined with any other aspect listed herein), the processor is configured to use event tracking to identify changes in medical data between snapshots, and to include only the altered medical data from previous snapshots as at least one of a first subset or a second subset of the medical data.

[0027] In the fifteenth aspect of this disclosure (which may be combined with any other aspect listed herein), the configuration file specifies the type of medical device and provides medical data to be received from the medical device in a first data format.

[0028] In the sixteenth aspect of this disclosure (which may be combined with any other aspect listed herein), the type of medical device includes at least one of a continuous renal replacement therapy (“CRRT”) machine, a peritoneal dialysis machine, a hemodialysis machine, a water purifier, or a nutritional supplement machine.

[0029] In the seventeenth aspect of this disclosure—which may be combined with any other aspect listed herein—the first data format includes JavaScript Object Notation (“JSON”), Hypertext Transfer Protocol (“HTTP”), or a binary protocol.

[0030] In the eighteenth aspect of this disclosure—which may be combined with any other aspect listed herein—the second data format includes the Health-Level 7 (“HL7”) protocol, the Fast Healthcare Interoperability Resources (“FHIR”) protocol, or a binary protocol.

[0031] In the nineteenth aspect of this disclosure (which may be combined with any other aspect listed herein), the wireless input port includes a Wi-Fi input port and At least one of the input ports, and the wireless output port includes at least one of the Wi-Fi output port or the cellular output port.

[0032] In the twentieth aspect of this disclosure (which may be combined with any other aspect listed herein), the medical data includes at least one of event information, alarm information, treatment programming information, or treatment information, the event information including transitions between the filling, residence, and discharge phases of a dialysis cycle, and the treatment information including estimated filling rate, discharge rate, and amount of ultrafiltration removed.

[0033] In the twenty-first aspect of this disclosure, the combination Figures 1 to 9 Any publicly disclosed structure and functionality with combination Figures 1 to 9 Any other publicly disclosed structure and functionality combined.

[0034] Based on this disclosure and the foregoing aspects, an advantage of this disclosure is that it provides an improved system for providing medical device data to medical device manufacturers.

[0035] Another advantage of this disclosure is the ability to use configuration files to configure certain drivers and / or hardware interfaces on the DCM.

[0036] Additional features and advantages are described in the following detailed description and accompanying drawings, and these additional features and advantages will become apparent from the description and accompanying drawings. The features and advantages described herein are not exhaustive; in particular, many additional features and advantages will become apparent to those skilled in the art from the accompanying drawings and description. Furthermore, any particular embodiment may not necessarily possess all the advantages listed herein, and it is expressly intended that individual advantageous embodiments be claimed separately. It should also be noted that the language used in the specification has been chosen primarily for readability and guidance purposes and is not intended to limit the scope of the subject matter of the invention. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of a DCM environment including a DCM and a medical device according to exemplary embodiments of the present disclosure.

[0038] Figure 2 This is another schematic diagram of a DCM environment according to exemplary embodiments of the present disclosure.

[0039] Figure 3 It is based on exemplary embodiments of this disclosure. Figure 1 and Figure 2 A schematic diagram of an exemplary DCM.

[0040] Figure 4 and Figure 5 This describes how the configuration file is installed according to exemplary embodiments of the present disclosure. Figures 1 to 3 A schematic diagram on the DCM.

[0041] Figure 6 Description of exemplary embodiments based on this disclosure Figure 4 and Figure 5 A diagram of the configuration file.

[0042] Figure 7 It is based on exemplary embodiments of this disclosure. Figures 1 to 3 A schematic diagram of a DCM including input ports, output ports, and a processor, wherein the processor comprises the above components. Figure 3 One or more applications for processing medical device data.

[0043] Figure 8 It is configured via a configuration file according to exemplary embodiments of this disclosure. Figures 1 to 5 as well as Figure 7 A flowchart of an exemplary procedure for DCM.

[0044] Figure 9 This is a use according to exemplary embodiments of the present disclosure. Figures 1 to 5 as well as Figure 7 A flowchart of an exemplary procedure for using a DCM to process data from a medical device. Detailed Implementation

[0045] A digital communication module (“DCM”) for transmitting data from a medical device is disclosed. An exemplary DCM is configured to receive medical device data from the medical device. The DCM transmits the medical device data in parallel to a local hospital network and an external server (such as a server belonging to the medical device manufacturer). In some embodiments, the DCM de-identifies the medical device data transmitted to the external server. The DCM may also add health and / or log data to the medical device data transmitted to the external server. Furthermore, in some embodiments, the DCM can convert the medical device data into different formats for the hospital system. The exemplary DCM is provided via a configuration file specifying input interface parameters, output interface parameters, device driver parameters, and / or data conversion parameters. Upon receiving the configuration file, the DCM is configured to provide specified input / output interfaces in addition to installing specified device drivers and providing data conversion / encryption mechanisms.

[0046] The DCM is configured to operate with many different types of medical devices and communicates via various interfaces, such as serial connections (e.g., RS-232 or RS-485), Ethernet connections, and Wi-Fi connections. Connectivity and / or Universal Serial Bus (“USB”) connectivity. The configurability of the DCM allows it to be used with many different types of medical devices, such as peritoneal dialysis machines, intensive care dialysis machines, continuous renal replacement therapy (“CRRT”) machines, hemodialysis machines, water preparation / purification devices, multivitamin systems, infusion pumps, etc. Furthermore, the configurability of the DCM allows its use in hospital systems configured in various ways. Therefore, the configurability of the DCM enables the transmission of medical device data to external servers without requiring any changes to the connection or networking of the medical device or hospital system.

[0047] Reference is made here to medical device data. As disclosed, medical device data (e.g., medical data) is generated in the medical device and transmitted to the DCM. Medical device data includes treatment programming information, which includes one or more parameters defining how the medical device operates to treat a patient. For peritoneal dialysis treatment, parameters may specify the amount (or rate) of fresh dialysis fluid to be pumped into the patient's peritoneal cavity, the amount of time the fluid remains in the patient's peritoneal cavity (i.e., residence time), and the amount (or rate) of used dialysis fluid and ultrafiltration (“UF”) pumped or drained from the patient at the end of the residence period. For treatments with multiple cycles, parameters may specify the filling, residence, and draining volumes for each cycle, as well as the total number of cycles to be performed during the treatment (where treatment is provided once daily, or separately during the day and night). Furthermore, parameters may specify the date / time / number of days (e.g., a schedule) to be performed via a medical fluid delivery system. In addition to the dialysis fluid concentration level (such as glucose level), parameters defining the therapy may also specify the total volume of dialysis fluid to be performed for each treatment. For intravenous therapy, parameters may include the volume of fluid to be infused, the drug to be infused, the drug concentration, the drug dosage, and / or the infusion rate.

[0048] Medical device data also includes event information related to the administration of treatment. Event information may include data on parameter values ​​that are measured, detected, or determined by the medical device. For example, while a prescribed therapy may specify treatment consisting of five separate cycles, each with a residence time of 45 minutes, a medical fluid delivery device may administer treatment providing fewer cycles, each with a residence time of 30 minutes. The medical device monitors how treatment is administered and provides parameters indicating the operation accordingly. Parameters for treatment data may include, for example, the total amount of dialysate administered to the patient, the number of cycles performed, the fill volume per cycle, the residence time per cycle, the drainage time / volume per cycle, the estimated amount of UF removed, the treatment start time / date, and / or the treatment end time / date. Processing data may also include calculated parameters, such as fill rate and drainage rate, determined by dividing the volume of fluid pumped by the time taken to pump. Treatment / event data may also include the 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 indications regarding whether the problem that caused the alarm was resolved or whether the alarm was silenced.

[0049] Medical device data also includes device machine logs, which contain diagnostic information, fault information, and more. Diagnostic information may include indications of internal operation of the medical device, such as faults related to pump operation, signal errors, communication errors, and software problems. Medical device data can be transmitted as a data stream or provided at periodic intervals. In some instances, medical device data may be transmitted when data events or other changes occur.

[0050] Reference is also made to log data and health data generated via an exemplary DCM. Log data includes identification of the therapy (medical) device type, identification of the therapy device serial number, timestamps of generating or receiving treatment data from the therapy device, the DCM identifier, snapshot timestamps, and / or DCM monotonic timestamps. Health information includes, for example, DCM system memory information, DCM central processing unit (“CPU”) usage information, network connectivity information, process / thread information, and information about the embedded software application.

[0051] While the following illustrates a DCM that divides medical device data into two separate data streams or subsets, it should be understood that a DCM can divide data into three or more separate streams. In some examples, each distinct stream may point to a different destination, include different data formats, and / or comprise different subsets of medical device data and / or log / health data. In addition to the manufacturer's analytics servers, medical device data may also be provided to drug / dialysis fluid manufacturers' data analytics servers, continuous quality improvement systems, auditors, regulators, etc.

[0052] I. DCM Environment Implementation Examples

[0053] Figure 1 This is a schematic 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 can be connected via a serial connection, Ethernet connection, USB connection, Wi-Fi connection, etc. The connection is made to the medical device. Exemplary DCM 102 may include a network gateway, such as an IoT gateway.

[0054] In an exemplary embodiment, DCM 102 is configured to receive medical device data only from medical device 104. This unidirectional communication configuration prevents other devices from accessing, programming, or otherwise communicating with medical device 104 via DCM 102. However, in some embodiments, DCM 102 may have a bidirectional communication link with medical device 104 to enable the transmission of data, programming instructions, or information to the medical device. Although in Figure 1 Only one DCM 102 and medical device 104 are shown in the diagram, but it should be understood that environment 100 may include dozens to hundreds or thousands of medical devices and corresponding DCMs.

[0055] An exemplary medical device 104 is configured to receive one or more parameters specifying 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 periodically (e.g., every 5 to 60 seconds and / or after data changes) store medical device data in the log files. New medical device data written to the log files is transmitted to the DCM 102. In some embodiments, the medical device 104 creates medical device data 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.

[0056] 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, control panels, or a touchscreen. The control interface 105 may also be configured to allow a user to navigate to specific windows or user interfaces on the screen of the medical device 104. The control interface 105 may also provide methods for operating or controlling the medical device 104.

[0057] 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 for treating a patient. These instructions may be obtained via a control interface 105. The processor or therapy module 107 also monitors for problems with device components, which are recorded as diagnostic information. The processor or therapy module 107 combines the operation of one or more pumps or other components to create medical device data for administering treatment. The processor or therapy module 107 transmits medical device data to the DCM 102.

[0058] The exemplary DCM environment 100 also includes a medical network 106 that 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 network infrastructure for establishing communication connections and routing data. The medical network 106 may include one or more firewalls that restrict access to authorized remote devices and / or servers only. The medical network 106 may include any local area network (LAN), Ethernet network, Wi-Fi network, or a combination thereof.

[0059] like Figure 1 As shown, DCM 102 can be coupled to medical network 106 via wired or wireless means. In some embodiments, the connection may include an Ethernet connection, a Wi-Fi connection, and / or a cellular connection. Additionally or alternatively, DCM 102 may have a serial connection to EMR server 108 (or hospital system 110) that bypasses medical network 106.

[0060] Figure 2 This is another schematic diagram of a 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, for example, include a Digi The 6UL module features an NXP i.MX6UL-2, Cortex-A7 528MHz CPU, and 256MB / 1GB NAND and DDR3 flash memory drivers. The DCM 102 can connect to the communication bus of the medical device 104 to receive data from the medical device. The DCM 102 (including...) Figure 1 The DCM also includes 802.11a / b / g / n / ac Wi-Fi radio and / or 4.2 Radio. The DCM 102 may include the Yocto Linux operating system and drivers for the Digi chipset.

[0061] An exemplary EMR server 108 is configured to manage patient EMRs stored in a database on storage 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 storage device 112, and store the parsed medical device data in the identified EMR. The EMR server 108 can also access one or more EMRs in response to a request message identifying the corresponding patient. The EMR server 108 can store medical device data in HL7 format, binary version 2 format, binary version 3 format, or Fast Healthcare Interoperability Resources (“FHIR”) format.

[0062] The exemplary DCM environment 100 may include a service portal, an enterprise resource planning system, a web portal, a business intelligence portal, a HIPAA-compliant database, a pharmacy system, etc. The DCM environment may also include a middleware system and / or an integration engine. The DCM environment 100 enables user devices (e.g., smartphones, laptops, workstations, tablets, etc.) to read and / or write medical device data stored in the EMR of the storage device 112.

[0063] Figure 1 The exemplary DCM environment 100 also includes an external network 120 communicatively coupled to the analytics server 122. The external network 120 may include any router, gateway, switch, cellular tower, and / or network infrastructure for routing data over a wide area network (WAN), such as the Internet, a cellular network (e.g., a 4G, 5G, or 6G cellular network), or a combination thereof. The external network 120 is communicatively coupled to the medical network 106 via one or more Ethernet and / or cellular connections. Domain addresses or subdomain addresses may be assigned to the medical network 106, identified by the external network 120, for routing data to and / or from devices connected to the medical network 106. In some embodiments, the cellular connection of the DCM 102 may bypass the medical network 106, instead coupling to the cellular network of the external network 120.

[0064] An exemplary analytics server 122 is configured to receive at least some medical device data from a DCM 102. The analytics server 122 stores the received data in a storage device 124, which may include any device configured for permanent data storage. The storage device 124 operates in conjunction with the analytics server 122 to enable data storage via the Platform as a Service (“PaaS”) framework through Amazon Web Services. (“AWS”) to store medical device data. In other embodiments, the storage device 124 may be configured to store medical device data in a Structured Query Language (“SQL”) database, a NoSQL database, or... The analysis server 122 may include one or more application programming interfaces (“APIs”) configured to receive medical device data from the DCM 102. The APIs may connect to ports of the analysis server 122, which are assigned one or more destination Internet Protocol (“IP”) addresses. The DCM 102 is configured with one or more destination IP addresses to enable the transmission of medical device data to the analysis server 122.

[0065] Analysis server 122 is configured to periodically analyze received medical device data to obtain certain key performance indicators (“KPIs”) related to the operation of medical device 104. KPIs may be related to treatment trends, component (e.g., pump or filter) usage, warning / alarm trends, etc. Analysis server 122 can analyze medical device data to determine recommendations and / or guidelines to improve the operation of medical device 104 and / or improve treatment protocols for certain disease conditions. For example, analysis server 122 can determine more optimized peritoneal dialysis programming parameters for a patient with some degree of renal failure. Analysis of medical device data may include analysis server 122, which provides standardization and parsing of DCM device logs and analysis of DCM health statistics.

[0066] In the example shown, medical device 104 is a PrisMax CRRT machine manufactured by Baxter International, Inc. It should be understood that in other embodiments, medical device 104 may include any other renal failure treatment machine, infusion pump, physiological sensors, etc. Medical device 104 may include, for example, infusion pumps (e.g., syringe pumps, linear peristaltic pumps, high-volume pumps (“LVP”), flow pumps, multichannel pumps), a multi-channel nutrition machine, an oxygen sensor, a respiratory monitor, a glucose meter, a blood pressure monitor, an electrocardiogram (“ECG”) monitor, a weighing scale, and / or a heart rate monitor.

[0067] Regarding treatment for kidney failure, the kidneys may fail for various reasons. Kidney failure leads to a variety of physiological disorders. For example, patients with kidney failure are no longer able to balance water and minerals or excrete the daily metabolic load. Toxic end products of nitrogen metabolism (urea, creatinine, uric acid, etc.) accumulate in the patient's blood and tissues. Kidney failure and decreased kidney function are treated with dialysis. Dialysis removes waste products, toxins, and excess water from the body, which would otherwise be cleared by normally functioning kidneys. Dialysis treatment for kidney replacement is crucial for many people because this treatment can save lives.

[0068] One type of treatment for kidney failure is hemodialysis (“HD”), which typically uses diffusion to remove waste products from a patient’s blood. A diffusion gradient occurs across the semi-osmotic dialyzer between the blood and an electrolyte solution (called the dialysate or dialysate) to induce diffusion.

[0069] Hemofiltration (“HF”) is an alternative renal replacement therapy that relies on the convective transport of toxins from the patient’s blood. HF is achieved by adding a replacement or alternative fluid (typically 10 to 90 liters) to the extracorporeal circuit during treatment. During HF treatment, the alternative fluid and the fluid accumulated by the patient between treatments are ultrafiltered, providing a convective transport mechanism, which is particularly advantageous in removing medium and large molecules (in hemodialysis, small amounts of waste are removed along with the fluid obtained between dialysis sessions; however, the solute drag caused by the ultrafiltration is insufficient to provide convective clearance).

[0070] Hemodialysis filtration (“HDF”) is a treatment modality that combines convective and diffusion clearance. HDF uses dialysate flowing through the dialyzer, similar to standard hemodialysis, to provide diffusion clearance. Additionally, a replacement solution is provided directly to the extracorporeal circuit to provide convective clearance.

[0071] Another treatment for kidney failure is peritoneal dialysis, which involves injecting a dialysis solution (also called dialysate) into the patient's peritoneal cavity via a catheter. The dialysate comes into contact with the peritoneum of the peritoneal cavity. Due to diffusion and osmosis, waste, toxins, and excess water enter the dialysate from the patient's bloodstream through the peritoneum; that is, an osmotic gradient appears on both sides of the membrane. The osmotic agent in dialysis provides this osmotic gradient. The used dialysate is drained from the patient, thus removing waste, toxins, and excess water from the body. This cycle is repeated, for example, many times.

[0072] There are various types of peritoneal dialysis therapy, including continuous ambulatory peritoneal dialysis (“CAPD”), automated peritoneal dialysis (“APD”), tidal flow dialysis, and continuous flow peritoneal dialysis (“CFPD”). CAPD is a manual dialysis treatment. Here, the patient manually connects the implanted catheter to the drainage tube to allow used dialysate to drain from the peritoneal cavity. The patient then connects the catheter to a fresh dialysate bag to infuse fresh dialysate into the patient through the catheter. The patient disconnects the catheter from the fresh dialysate bag, allowing the dialysate to remain in the peritoneal cavity, where waste, toxins, and excess water are transferred. After the retention 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 a significant investment of time and effort from the patient, leaving ample room for improvement.

[0073] Automated peritoneal dialysis (“APD”) is similar to CAPD in that dialysis treatment involves drainage, filling, and retention cycles. However, APD machines typically perform cycles automatically while the patient is asleep. APD machines eliminate the need for patients to manually perform treatment cycles or transport supplies during the day. An APD machine is fluid-connected to an implanted catheter, a source of fresh dialysate or dialysate bags, and a fluid drainage tube. The APD machine pumps fresh dialysate from the dialysate source through the catheter and into the patient's peritoneal cavity. The APD machine also allows dialysate to remain in the cavity and allows for the removal of waste, toxins, and excess water. The source may include multiple sterile dialysate bags.

[0074] The APD machine pumps used dialysis fluid from the peritoneal cavity through a catheter to a drainage tube. Similar to the manual procedure, there are several cycles of draining, filling, and retention during dialysis. The “last fill” occurs at the end of APD and remains in the patient’s peritoneal cavity until the next treatment.

[0075] II. DCM Implementation Examples

[0076] Figure 3 It is based on exemplary embodiments of this disclosure. Figure 1 and Figure 2 A schematic diagram of an exemplary DCM 102 is provided. The exemplary DCM 102 includes a data device manager 302 configured to generate two parallel data streams for medical device data received from a medical device 104. The DCM 102 also includes a log manager 304 and a system health monitor 306 to obtain or provide information related to the DCM. For a first data stream or subset provided to an analytics server 122, the DCM 102 includes an external agent 310, an external interface 312, and an external persistent storage device 314. For a second data stream or subset provided to an EMR server 108, the DCM includes an internal agent 320, an internal interface 322, and an internal persistent storage device 324.

[0077] Exemplary components 302 to 312, 320, and 322 of the DCM can be implemented using one or more computer programs or applications. The program or application can 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 disk or optical disk, optical storage, or other storage media. The instructions can be configured to be executed by a processor of the DCM 102, which, in executing the series of computer instructions, performs or facilitates the execution of all or part of the methods and programs disclosed herein. Permanent storage devices 314 and 324 can include any memory device, including RAM, ROM, flash memory, etc.

[0078] An exemplary data device manager 302 is configured to engage with medical device 104 to receive medical device data. The data device manager 302 is configured to create snapshots of the medical device data at discrete time points. Time periods can be specified by a configuration file (e.g., configuration file 342), such as intervals of 5 seconds, 10 seconds, 30 seconds, 60 seconds, etc. For each snapshot, the data device manager 302 reads the most recently received data from medical device 104. In this way, the device data manager 302 provides periodic updates on the status of medical device 104.

[0079] In the example, medical device 104 can transmit medical device data 330 in a continuous stream, at periodic intervals, or after data changes. Medical device 104 can transmit medical device data 330 in a log file or message stream. Device data manager 302 compiles the data received since the last snapshot interval. When the next interval approaches, device data manager 302 compiles the latest data into the snapshot to provide a representation of medical device 104 at that point in time. If multiple events occur during the compilation period, device data manager 302 can include only the most recent event or all events that occurred during that period.

[0080] In some instances, the device data manager 302 can compare the current snapshot with previous snapshots. Based on the comparison, the device data manager 302 can include only the medical device data in the current snapshot that has changed since the previous snapshot. This comparison reduces the amount of data transmitted in each snapshot, allowing only new and / or updated medical device data 330 to be transmitted. For example, the CRRT medical device 104 may continuously transmit estimated UF removal values, which typically remain unchanged throughout the fill and stay cycles of PD treatment. Therefore, the device data manager 302 only includes the UF removal value when it changes. In another example, an alarm may be activated at a certain time. The device status can be included in the medical device data 330, indicating that the alarm remains active. However, the device data manager 302 only includes notifications of the alarm activation time (and alarm type) in the first snapshot and the time when the alarm is muted or reset in a second subsequent snapshot, excluding indications that the alarm was active in intermediate snapshots.

[0081] In other embodiments, medical device 104 may selectively transmit only medical device data that has changed from previous values ​​or reflects new events. In these instances, device data manager 302 writes the received medical device data 302 to an appropriate snapshot.

[0082] By combining a snapshot of medical device data 330, the exemplary device data manager 302 creates two separate datasets or streams. A first dataset or stream 316 is used for analytics server 122. A second data subset or stream 326 is used for EMR server 108 and / or hospital system 110. The first data stream or subset 316 may include the same medical device data 330 from the snapshot as the second data stream or subset 326. In other embodiments, more or less medical device data 330 from the snapshot may be included compared to the second data subset or stream 326. For example, the device data manager 302 may be configured to include diagnostic data (identified by metadata, data field labels, layout, etc.) in the first data stream or subset 316, but not in the second data stream or subset 326. Furthermore, the device manager 302 may include patient identification data in the second data stream or subset 326, but not any patient identification data in the first data stream or subset 316.

[0083] Exemplary DCM 102 includes an external agent 310 for deidentifying a first data stream or subset 316 to generate a deidentified first data stream or subset 318. The external agent 310 can be configured to search for data tags or keywords indicating patient names, hospital-assigned identifiers, social security numbers, etc. In some instances, patient-specific information can be replaced with (randomly) generated session identifiers, which are used by the analysis server 122 to associate medical device data from the same treatment. In other embodiments, patient identification information is removed or deleted by the external agent 310.

[0084] The exemplary external agent 310 is also configured to combine or include log and / or health data 319 in or within the deidentified first data stream or subset 318. The log data is generated by the log manager 304 and includes identification of the medical device type, identification of the medical device serial number, timestamps of medical device data 330 generated by or received from medical device 104, an identifier of DCM 102, timestamps of snapshots created by the device data manager 302, and DCM monotonic timestamps. The identification of the medical device type, the identification of the medical device serial number, and the identifier of DCM 102 can be specified in the configuration file 342. In some instances, the identification of the medical device type and the identification of the medical device serial number can be reported by medical device 104. The log manager 304 is configured to store this information and create appropriate timestamps when receiving medical device data 330 and / or creating snapshots. The log manager 304 then transmits the log data to the external agent 310 for each snapshot corresponding to the deidentified first data stream or subset 318 transmitted to the analytics server 122.

[0085] An exemplary system health manager 306 is configured to acquire and / or determine health information relayed to DCM 102. System health manager 306 is configured to transmit DCM system memory information (related to persistent storage devices 314 and 324), DCM CPU usage information, network connectivity information, process / thread information, and other information related to one or more software applications running on DCM 102 to external agent 310. To acquire this information, system health manager 306 is configured to access and / or read memory usage information of persistent storage devices 314 and 324. Furthermore, system health manager 306 is configured to monitor one or more processors of DCM 102 that implement the operations described herein. System health monitor 306 also monitors network connectivity and / or detects network connectivity loss via the lack of received acknowledgment messages from analysis server 122 and / or EMR server 108. Similar to log manager 304, system health manager 306 transmits health information to external agent 310 for transmission along with a deidentified first data stream or subset 318. In some instances, configuration file 342 may specify which information will be acquired by system health monitor 306 and / or specify which health information will be provided to external agent 310 and / or internal agent 320.

[0086] An exemplary external agent 310 is configured to de-identify a first data stream or subset 318 and / or log / health data 319 for transmission to the analytics server 122. The external agent 310 receives the destination IP address of the analytics server 122 from a configuration file 342. The external agent may also receive domain connectivity information for the medical network 106 and / or API connectivity information for the analytics server 122 from the configuration file 342. The external agent 310 uses the destination address and network domain information provided by the configuration file 342 to create one or more messages with the de-identified first data stream or subset 318 and / or log / health data 319 for transmission to the analytics server 122.

[0087] In some embodiments, the external agent 310 encrypts one or more messages including a deidentified first data stream or subset 318 and / or log / health data 319. The external agent 310 may use an encryption protocol and / or private key specified or provided by configuration file 342. For example, configuration file 342 may specify that the external agent 310 is configured to use Transport Layer Security (“TLS”) and / or AES 256GCM ciphers for encryption. The external agent transmits the (encrypted) messages to external interface 312.

[0088] In some embodiments, external interface 312 (and / or internal interface 322) is configured to use MQ telemetry transport (“MQTT”) to transmit messages with deidentified first data stream or subset 318 and / or log / health data 319 to analytics server 122. In this example, external interface 312 is configured as a publisher, and analytics server 122 is configured as a broker. In other examples, internal interface 312 (and / or internal interface 322) may be configured to communicate using a minimal lower-level protocol (“MLLP”).

[0089] In some instances, exemplary external interface 312 is configured to determine whether a valid connection to analytics server 122 exists. External interface 312 may transmit periodic pings to analytics server 122 to determine network status based on responses to the pings. In other examples, external interface 312 may determine whether an acknowledgment message has been received in response to the transmission of a snapshot of deidentified first data stream or subset 318 and / or log / health data 319. If no acknowledgment message is received within a specified threshold, external interface 312 determines that a network connection to analytics server 122 has been lost. Upon determining that no connection to analytics server 122 exists, external interface 312 is configured to store an encrypted message containing deidentified first data stream or subset 318 and / or log / health data 319 to external persistent storage device 314. External interface 312 stores subsequent snapshots of messages containing deidentified first data stream or subset 318 and / or log / health data 311 to storage device 314 until the network connection is re-established. At this time, the external interface 312 transmits all messages stored in the memory device 314 to the analysis server 122.

[0090] In some cases, a connection to the analysis server 122 is not established. In these examples, the external interface 312 is configured to store the deidentified first data stream or subset 318 and / or log / health data 319 into the storage device 314 until the data can be manually retrieved by an operator who connects a computer or USB storage device to the DCM 102. The external interface 312 can be configured via configuration file 342 to store data for a specified number of hours or days. After the specified number of hours or days has elapsed, the external interface 312 can overwrite the oldest data with newly received data.

[0091] If a connection to analytics server 122 exists, external interface 312 transmits one or more messages to analytics server 122 (e.g., via a specified API at a specified IP address) containing a deidentified first data stream or subset 318 and / or log / health data 319. In some embodiments, external interface 312 may perform automatic authentication with analytics server 122 before transmitting the deidentified first data stream or subset 318 and / or log / health data 319. In an example, configuration file 342 may include authentication information, such as an identifier of DCM 102 and / or a unique password for DCM 102. External interface 312 first transmits the authentication information to analytics interface 122. After receiving an acceptance message from analytics server 122, external interface 312 transmits one or more messages to analytics server 122 containing the deidentified first data stream or subset 318 and / or log / health data 319. In some instances, external interface 312 uses the authentication information to establish a session with analytics server 122. During this session, external interface 312 can transmit a deidentified first data stream or subset 318 and / or subsequent snapshots of log / health data 319 to analytics server 122 without re-authentication. The session may time out if no data is received within a specified time period (such as 5 minutes).

[0092] In addition to transmitting the deidentified first data stream or subset 318 and / or log / health data 319 to the analytics server 122, the DCM 102 also transmits a second data stream or subset 326 to the EMR server 108. For example... Figure 3 As shown, the device data manager 302 transmits a second data stream or subset 326 to the internal agent 320. Each transmission may include a snapshot of the second data stream or subset 326.

[0093] In some embodiments, the internal agent 320 is communicatively coupled to the log manager 304 and / or the system health manager 306. In these embodiments, the internal agent receives at least a portion of the log / health data 319 provided to the external agent 310. For example, the internal agent may receive information from the log manager 304 indicating the type of medical device, the serial number of the medical device, and / or the timestamps of data generated or received from the medical device 104. The internal agent may combine the log data 319 with a second data stream or subset 326, for example. In other embodiments, the internal agent 320 does not receive any log / health data 319.

[0094] After combining any log / health data 319 with the second data stream or subset 326, the internal agent 320 is configured to format the data to a format compatible with or required by the EMR server 108. In other words, the internal agent creates transformations of the second data stream or subset 328 and / or log data 319. The transformation type can be specified by configuration file 342. The transformation can be, for example, from JSON to HL7, binary, and / or FHIR. The internal agent 320 may include one or more files and / or algorithms that, for example, specify how to convert the JSON-formatted second data stream or subset 326 and / or log data 319 to HL7, binary, and / or FHIR. The files and / or algorithms can identify JSON data by location, data tags, field names, and / or metadata, and specify how to transform the data, including transformations of data tag names, metadata names, number formats, locations, etc. The internal agent 320 then transmits the transformed second data stream or subset 328 and / or log data 319 to the internal interface 322.

[0095] The exemplary internal interface 322 is configured to check the connection to the EMR server 108 in a manner similar to how the external interface 312 checks the connection to the analysis server 122. Furthermore, for serial connections, the internal interface 326 can check for the presence of a serial connector entering the DCM 102 port. If no connection exists, the internal interface 322 stores the converted second data stream or subset 328 and / or log data 319 to the internal permanent storage device 324. If a connection exists, the internal interface 322 transmits one or more messages containing the second data stream or subset 328 and / or log data 319 to the EMR server 108 (including any previously stored messages containing a previous snapshot of the second data stream or subset 326 and / or log data 319 in the storage device 324). In some embodiments, if the EMR server 108 supports conversion, the internal interface 322 can encrypt messages containing the converted second data stream or subset 328 and / or log data 319 (for non-serial connections).

[0096] Figure 3 The exemplary DCM 102 also includes a configuration file manager 350 for storing and / or processing one or more configuration files 342. The configuration file manager 350 is configured to receive configuration files 342 from a computer 400 or a server 500, as combined below. Figure 4 and Figure 5 As stated above.

[0097] Configuration file manager 350 reads configuration file 342 and configures the log manager 304, system health manager 306, device data manager 302, external agent 310, external interface 312, internal agent 320, and / or internal interface 322 specified in file 342. For log manager 304, this may include writing DCM identifiers, medical device types, medical device identifiers, etc., for example, to register parameters or variables of log manager 304. For system health manager 306, this may include specifying parameters / attributes of the processor / CPU of the memory devices 314, 324, and / or DCM 102 to be monitored. For internal agent 320, this may include specifying data types for conversion.

[0098] In some instances, the configuration file manager 350 can also specify the conversion file type for the external agent 310. Furthermore, the configuration file manager 350 configures the device data manager 302 based on the duration between snapshots, the type of medical device data to be included in separate streams and / or subsets 316, 326, and the type 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 350 also reads the configuration file 342 to specify network credentials, authentication information, encryption keys, API identifiers, destination IP addresses, etc., for the external interface 312 and the internal interface 322.

[0099] The configuration file manager 350 may also define or otherwise provide a user interface that enables users of computer 600 or server 700 to view and / or modify the stored configuration file 342. The user interface may include fields for configuring network connectivity of DCM 102, specifying an identifier for DCM 102, specifying a username / password for accessing DCM 102, specifying parameters for configuration file 342, and / or installing software (such as connection clients or applications).

[0100] Figure 4 This illustrates an embodiment of the present disclosure, mounted on a DCM 102 via a computer 400. Figure 3 A schematic diagram of configuration file 342 is provided. In this example, computer 400 is directly connected to DCM 102 via Ethernet, serial connection, or USB connection. Computer 400 can be operated by hospital technicians or technicians associated with the manufacturer of medical device 104.

[0101] After connection, DCM 102 initiates an interface for display on computer 400 via configuration file manager 350. During this time, the operator of computer 400 can edit and / or enter information into fields related to configuration, networking, software, and / or security in the user interface. Furthermore, via configuration file manager 350, computer 400 is configured to allow the operator to specify parameters or attributes of configuration file 342. After specifying the parameters and / or attributes, computer 400 transmits configuration file 342 to DCM 102. Configuration manager 350 receives configuration file 344 and thus provides or otherwise configures DCM 102.

[0102] Figure 5 This diagram illustrates server 500 installing configuration file 342 on DCM 102. In this example, DCM 102 may be configured with the IP address of server 500 at manufacturing time. DCM 102 may also be configured with credentials and / or network settings for accessing medical network 106 and / or information (such as device type) related to medical device 104. After DCM 102 is powered on, DCM 102 transmits a request message to server 500 requesting configuration file 342. This request message may include authentication and / or verification information and / or the IP address of DCM 102. Server 500 may store one or more different types of configuration files based on hospital network and / or local configuration preferences. Server 500 determines which configuration file to assign to DCM 102, for example, based on the type of medical device 104, medical network 106, etc.

[0103] In response, after verification, server 500 transmits the selected configuration file 342 to DCM 102 via external network 120 and medical network 106. DCM 102 receives configuration file 342, and configuration file 342 is... Figure 3 The configuration file manager 350 is used to provide or otherwise configure DCM 102. Figure 5 The configuration shown enables automatic configuration of DCM 102 without the need for technical personnel or direct computer connection. In some embodiments, server 500 may include Figures 1 to 3 Analysis server 122.

[0104] Figure 6 This diagram illustrates parameters and / or attributes of a configuration file 342 according to an exemplary embodiment of the present disclosure. The configuration file 342 can be generated by... Figure 4 The operator of the computer 400 can choose, or it can be... Figure 5The server 500 is specified. Configuration file 342 includes parameters for medical device type 602. The selection of the medical device type provides an indication of the type and / or format of the medical device data to be received. The selection of the medical device type parameter 602 also allows the DCM 102 to install one or more drivers for processing data from that medical device type. It should be understood that drivers can be stored on the DCM 102 and installed only when the corresponding device type parameter is selected.

[0105] Configuration file 342 also includes an input port type parameter 620. The selection of input port type parameter 620 provides an indication of which input ports of the DCM 102 should be provided and / or activated. The DCM 102 can also install one or more drivers for the selected input ports, specifying how data from the medical device should be converted, for example, into a standardized JSON format. Configuration file 342 also includes parameters for external interface 630 and internal interface 640. This includes data conversion type, connection protocol, and / or encrypted data protection protocol. This also includes the selection of one or more hardware output ports of the DCM 102 that should be provided and / or activated.

[0106] Configuration file 342 also includes parameters for DCM information 650, such as identification information, IP or network address, snapshot period, storage device persistence information, and health statistics to be monitored. DCM information parameters 650 may also include external addresses and / or credentials for accessing analytics server 122 and internal addresses and / or credentials for accessing EMR server 108.

[0107] In some embodiments, the configuration file manager 350 may display something similar to Figure 6 The interface for the parameters is shown. Users can easily select parameters by choosing the corresponding button or entering information in the displayed fields. In other embodiments, the configuration file may be text-based, XML-based, and / or JSON-based, wherein parameters are specified in certain parts of the file or identified by relevant data tags / fields. It should be understood that configuration file 342 enables data transfer from virtually any type of medical device to an external server in any desired format without requiring changes to the medical device or network infrastructure.

[0108] Figure 7 This is a schematic diagram of a DCM 102 including an input port 702, an output port 704, and a processor 706 according to an exemplary embodiment of the present disclosure. The processor 706 includes the above-described combination. Figure 3The aforementioned application is used to process data from a medical device. In the example shown, input port 702 operates in conjunction with device data manager 302, thereby communicatively coupled to medical device 104. Input port 704 may include one or more serial ports, Ethernet ports, Wi-Fi ports, etc. Port or USB port. It should be understood that DCM 102 may include fewer ports. Profile 342 specifies which ports are activated for communication with medical device 104, including the installation of appropriate drivers.

[0109] Similarly, DCM 102 includes an output port 704 for connecting to the analysis server 122 and the EMR server 108 via the hospital network 108. In the example shown, output port 702 operates in conjunction with interfaces 312 and 322 to communicatively couple to the analysis server 22 and the EMR server 108. Output port 704 may include one or more serial ports, Ethernet ports, Wi-Fi ports, and / or cellular ports. It should be understood that DCM 102 may include fewer or more output ports. Profile 342 specifies which ports are activated for communicating with the medical device 104, including the installation of appropriate drivers.

[0110] Exemplary processor 706 specifies execution combination Figure 3 One or more instructions for the operation. Processor 706 includes input module 710, which includes device data manager 302 and medical device driver 712. Exemplary device driver 712 is installed based on which type of medical device 104 is used with DCM 102. Each driver includes instructions on how to format or structure data from the medical device, which enables device data manager 302 to recognize different data types for patient deidentification or inclusion in first and second data streams or subsets 316 / 326.

[0111] The exemplary processor 706 also includes an external agent 310 as described above and an encryption module 714 that operates in conjunction with interface 312. The processor 706 further includes an internal agent 320 and another encryption module 716 that operates in conjunction with interface 322. Additionally, the processor 706 includes a configuration file manager 350 for configuring DCM 102 as specified by configuration file 342.

[0112] Processor 706 also includes a data conversion module 718. An exemplary data conversion module 718 is configured to convert medical device data from a first format specified in configuration file 342 to a second format. Different data types of data conversion module 718 define how data is converted from different formats to a specified second format, such as HL7, binary v2, binary v3, and / or FHIR. In some embodiments, module 718 may include portions for JSON, XML, HTTP, HTML, etc.

[0113] Figure 7 The exemplary DCM 102 can be configured as an IoT agent, providing a secure, bidirectional connection from the DCM to the analytics server 122 by leveraging an IoT framework. The DCM 102 can use the IoT framework for device management, configuration, security, and the transmission of connectivity health statistics. In some examples, the DCM 102 is configured for IoT device shadowing of the analytics server 122 to transmit a deidentified first data stream or subset 318 and / or log / health data 319.

[0114] Processor 706 may include digital and analog circuitry configured as a microprocessor, application-specific integrated circuit (“ASIC”), controller, etc. For example, processor 106 may include Digi The 6UL module features an NXP i.MX6UL-2, Cortex-A7 528MHz CPU, and 256MB / 1GB NAND and DDR3 flash memory drivers. The DCM 102 also includes an 802.11a / b / g / n / ac Wi-Fi radio connected to the corresponding input port 702 and / or output port 704. 4.2 Radio. The processor 106 of the DCM 102 can be configured to operate with the Yocto Linux operating system and includes drivers for the Digi chipset. The processor 106 can operate connectivity applications that allow users to manage network and configuration settings via the configuration file manager 350. The connectivity applications also allow the DCM 102 to receive remotely provided software and firmware updates.

[0115] III. Exemplary DCM Configuration Procedure

[0116] Figure 8 This is a flowchart of an exemplary procedure 800 for configuring DCM 102 via configuration file 342 according to an exemplary embodiment of the present disclosure. Although referenced... Figure 8The flowchart shown illustrates program 800, but it should be understood that many other methods can be used to perform the steps associated with program 800. For example, the order of the blocks can be changed, some blocks can be combined with other blocks, and the blocks themselves are optional. In embodiments, the number of blocks can be varied. Furthermore, the step of receiving confirmation of transmission configuration file 342 can be omitted. The actions described in program 800 are specified by one or more instructions and can be executed among multiple devices, including, for example, DCM 102, computer 400, and / or server 500.

[0117] When DCM 102 receives or otherwise obtains configuration file 342, exemplary program 800 in Figure 8 The process begins (box 802). In some embodiments, configuration file 342 may be created locally on DCM 102 via a user interface provided by configuration file manager 350. After acquisition, DCM 102 stores the configuration file (box 804). DCM 102 then reads configuration file 342 to determine which parameters / attributes are specified. Based on the specified parameters / attributes, DCM 102 accesses and installs the corresponding device driver for processing data from the specified medical device type (box 806).

[0118] The exemplary DCM 102 also provides one or more input ports for communication with the medical device 104 based on specified parameters / attributes of configuration file 342 (block 808). The exemplary DCM 102 also provides one or more output ports for communication with the analysis server 122 based on specified parameters / attributes of configuration file 342 (block 810). Furthermore, the exemplary DCM 102 provides one or more output ports for communication with the EMR server 108 based on specified parameters / attributes of configuration file 342 (block 812). Providing input / output ports may include activating identified input and output ports and installing any associated drivers.

[0119] In addition, DCM 102 provides a data manager to convert medical device data from the medical device into the format specified in configuration file 342 for transmission to EMR server 108 (block 816). In some instances, DCM 102 provides a data manager to convert medical device data into a standardized format for processing by analysis server 122. DCM 102 can then complete the configuration process by transmitting acknowledgment messages 817 (block 818), which, for example, indicate the following for each medical device: Figure 4 and Figure 5The computer 400 or server 500 is configured. Then, the exemplary program 800 ends, and the DCM 102 is ready to process the medical device data.

[0120] IV. Exemplary DCM Medical Device Data Processing Procedure

[0121] Figure 9 This is a flowchart of an exemplary procedure 900 for processing medical device data via DCM 102 according to an exemplary embodiment of the present disclosure. Although referenced... Figure 9 The flowchart shown illustrates program 900, but it should be understood that many other methods can be used to perform the steps associated with program 900. For example, the order of the blocks can be changed, some blocks can be combined with other blocks, and the blocks themselves are optional. In embodiments, the number of blocks can be varied. Furthermore, the step of encrypting a subset of data can be omitted. The actions described in program 900 are specified by one or more instructions and can be performed among multiple devices, including, for example, DCM 102, medical device 104, analysis server 122, and / or EMR server 108.

[0122] When DCM 102 receives medical device data 330 from medical device 104, which is communicatively coupled, exemplary procedure 900 begins (block 902). DCM 102 records snapshots of the received data based on periodic intervals and creates two separate data streams or subsets (block 904). In some instances, the same medical device data is used for each subset. In other instances, the data subsets may include different medical device data or a portion of the same medical device data.

[0123] For the first data stream or subset, DCM 102 deidentifies the data to create deidentified data 318 (box 906). This includes removing any data that could be used to identify the patient. In some instances, the patient identifier is replaced with a session identifier and / or a random character set. DCM 102 then adds log / health data 319 to the deidentified data 318 (box 908). DCM 102 can then encrypt the deidentified data 318 and / or the log / health data (box 910).

[0124] Then, DCM 102 checks for the existence of a connection to analytics server 122 (block 912). In some instances, DCM 102 may use the Message Queuing Telemetry Transport (MQTT) messaging protocol to check the connection status. If no connection exists, DCM 102 stores one or more encrypted messages containing deidentified data 318 and / or log / health data 319 to a persistent storage device (block 914). DCM 102 continues to store subsequent encrypted messages until a data connection is detected. Once a data connection is detected, DCM 102 transmits the encrypted message including deidentified data 318 and / or log / health data 319 to analytics server 122 via one or more networks 106, 120 (block 916). The exemplary procedure 900 then returns to block 902 for processing newly received medical device data.

[0125] For a second stream or subset of medical device data, DCM 102 converts the data to a format specified for EMR server 108 (box 920). This may include converting the medical device data to JSON, HL7, binary version 2 / 3, FHIR, XML, and / or HTTP formats. DCM 102 can then add log / health data 319 to the converted data 328 (box 922). DCM 102 can then encrypt the converted data 328 and / or the log / health data 319 (box 924).

[0126] Then, DCM 102 checks for the existence of a connection to EMR server 108 (block 926). In some instances, DCM 102 may use the MQTT messaging protocol or the Minimal Lower-Level Protocol (“MLLP”) to check the connection status. If no connection exists, DCM 102 stores one or more encrypted messages containing the transformed data 328 and / or log / health data 319 to a persistent storage device (block 928). DCM 102 continues to store subsequent encrypted messages until a data connection is detected. Once a data connection is detected, DCM 102 transmits the encrypted message including the transformed data 328 and / or log / health data 319 to EMR server 108 via medical network 106 and / or a serial connection (block 930). The exemplary procedure 900 then returns to block 902 for processing newly received medical device data.

[0127] V. Conclusion

[0128] It should be understood that various changes and modifications to the presently preferred embodiments described herein will be apparent to those skilled in the art. These changes and modifications can be made without departing from the spirit and scope of the subject matter or diminishing its intended advantages. Therefore, it is intended that these changes and modifications be covered by the appended claims.

Claims

1. A digital communication device, comprising: An input interface configured for communication coupling with a medical device, the input interface including a serial input port, an Ethernet input port, and a wireless input port; An output interface configured for communication coupling with a medical network, the output interface including at least one of a serial output port, an Ethernet output port, or a wireless output port; A memory device configured to store at least one configuration file and driver for the input port and the output port; as well as A processor, communicatively coupled to the input interface, the output interface, and the memory device, is configured to: A configuration file is received from a management computer via the output interface. The configuration file specifies one of the input ports of the input interface and at least one output port of the output interface, a first data format, and a second data format. The configuration file is stored in the memory device. As specified in the configuration file, the input port is identified as one of the serial input port, the Ethernet input port, or the wireless input port, and the at least one output port is identified as one of the serial output port, the Ethernet output port, or the wireless output port. Install drivers for the identified output and input ports specified in the configuration file. Provide a specified input port for the input interface to receive medical data from the medical device in accordance with the first data format, and Provide at least one specified output port for the output interface to transmit at least a portion of the received medical data using the first data format and the second data format.

2. The apparatus of claim 1, wherein, The processor is configured to: The medical data is received from the medical device according to the first data format via the input interface. A first subset of the medical data is selected from one of the output ports specified in the configuration file for transmission via the output interface in the first data format. Convert the second subset of the medical data into the second data format, and The second subset of the medical data is transmitted in accordance with the second data format for transmission via an output port that is the same as or different from the output port specified by the configuration file.

3. The device according to claim 2, wherein, The first subset of the medical data is the same as the second subset of the medical data.

4. The device according to claim 2, wherein, The output interface provides communication coupling with at least one of an electronic medical record (EMR) server, middleware server, or integration engine via the medical network, and The processor is configured to transmit a second subset of the medical data to at least one of the electronic medical record (EMR) server, the middleware server, or the integration engine, using an output port that is the same as or different from the output port specified in the configuration file, in accordance with the second data format.

5. The device according to claim 2, wherein, At least one of the Ethernet output port and the wireless output port provides communication coupling with a remote server outside the medical network, and The processor is configured to transmit a first subset of the medical data to the remote server using at least one of the Ethernet output port or the wireless output port, in accordance with the first data format.

6. The device according to claim 2, wherein, The processor includes a first connectivity agent and uses a messaging protocol to transmit a first subset of the medical data in accordance with the first data format.

7. The device according to claim 6, wherein, The messaging protocol includes: Message Queuing Telemetry Transport (MQTT) publish-subscribe network protocol.

8. The device according to claim 2, wherein, The configuration file specifies a first destination network address, which is used to receive a first subset of the medical data according to the first data format. The configuration file also specifies a second destination network address, which is used to receive a second subset of the medical data according to the second data format. Specifically, the first destination network address is associated with a network domain outside the medical network, and the second destination network address is associated with a network domain that includes the medical network.

9. The device according to claim 2, wherein, The processor is configured to: Generate log data and health data; The log data and the health data are included in the first subset of the medical data through one of the output ports specified in the configuration file, for transmission via the output interface in the first data format; Convert the log data into the second data format; as well as The log data is included in the second subset of the medical data for transmission via the same or different output port as specified in the configuration file.

10. The device according to claim 9, wherein, The log data includes at least one of the following: identification of the medical device type, identification of the medical device serial number, timestamps indicating that the received medical data was generated by the medical device or received by the processor from the medical device, the device identifier, timestamps of the first subset of the medical data, or monotonic timestamps for the log data. The health data includes: information related to the memory device, CPU usage information, network connectivity information, process / thread information, or information related to software operated by the processor, the software being used to process the first subset and the second subset of the medical data for transmission.

11. The device according to claim 2, wherein, The processor is configured to perform at least one of the following operations: Anonymize the patient information included in the first subset of the medical data prior to transmission, or The first subset of the medical data prior to transmission is encrypted.

12. The device according to claim 2, wherein, The processor is configured to: Receive the stream of the medical data; Snapshots of the medical data are created at periodic intervals; and Provide the snapshot of the medical data as at least one of the first subset or the second subset of the medical data.

13. The device according to claim 12, wherein, The periodic interval has a period between 5 seconds and 60 seconds.

14. The device according to claim 12, wherein, The processor is configured to: Event tracking is used to identify changes in the medical data between snapshots; and Only the altered medical data from the previous snapshot is included as at least one of the first subset or the second subset of the medical data.

15. The device according to claim 1, wherein, The configuration file specifies the type of the medical device and provides the medical data to be received from the medical device in the first data format.

16. The device according to claim 15, wherein, The medical device includes at least one of the following: a continuous renal replacement therapy (CRRT) machine, a peritoneal dialysis machine, a hemodialysis machine, a water purifier, or a nutritional supplement machine.

17. The device according to claim 1, wherein, The first data format includes: JavaScript Object Notation ("JSON"), Hypertext Transfer Protocol ("HTTP"), or a binary protocol.

18. The device according to claim 1, wherein, The second data format includes: Health-Level 7 ("HL7") protocol, Fast Healthcare Interoperability Resources ("FHIR") protocol, or binary protocol.

19. The device according to claim 1, wherein, The wireless input port includes at least one of a Wi-Fi input port and a Bluetooth input port, and The wireless output port includes at least one of a Wi-Fi output port or a cellular output port.

20. The device according to claim 1, wherein, The medical data includes at least one of the following: Event information, including the transitions between the filling, residence, and discharge phases of a dialysis cycle; Alarm message; Treatment programming information; or Treatment information, including estimated filling rate, discharge rate, and amount of ultrafiltration removed.

Images