Digital communication module for transmission of data from a medical device

Abstract

To provide a digital communication module for transmission of data from a suitable medical device.SOLUTION: A digital communication module for transmission of data from a medical device is disclosed. In one embodiment, the digital communication device includes an input interface configured for communicative coupling to a medical device, and an output interface configured for communicative coupling to a medical network. A processor of the digital communication device receives a configuration file that defines 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 and output ports specified by the configuration file, provisions the input interface with the specified input port, and provisions the output interface with the at least one specified output port.SELECTED DRAWING: Figure 1

Description

[Background technology]

[0001] A medical network typically has a significant number of connected medical devices. The network receives data from the medical devices. After receiving the data, a server connected to the network stores the data in a patient electronic medical record ("EMR") or relays the data to some hospital system, such as a pharmacy system. For security reasons, data collected from the medical devices is made available internally only to user devices that have permission to connect to the medical network. As a result of this network security, third parties, such as medical device manufacturers, generally do not have access to data generated by their deployed medical devices.

[0002] Some manufacturers attempt to obtain medical device data by having sales representatives or technicians physically visit each medical device and remove at least some of the device data, including diagnostic information. However, this is an extremely labor-intensive process. In addition, this manual process often overlooks or misses many medical devices from data collection due to the time and expense associated with data collection. This can create gaps when the data is later analyzed. Furthermore, this manual collection method is not timely, as the data may only be analyzed days to weeks, or even months, after collection.

[0003] Some other medical device manufacturers are granted limited access to medical device data stored within medical networks. In these cases, the device manufacturers have access to data repositories that are separate from patient records and hospital systems. One problem is that the data is limited to medical data transmitted from the medical device and may not 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 handling, processing, and analysis of the data difficult or impossible. Also, a device manufacturer with medical devices in dozens to hundreds of different hospital systems (each with its own unique protocols and data storage requirements) would need to access each system separately and perform any data conversions to generate a uniform and usable data set.

[0004] The problems described above deprive medical device manufacturers of valuable medical device data. For example, device manufacturers can use device data to address device issues, identify device performance trends, identify treatment trends, identify device performance recommendations, or help plan the development of next-generation devices. The lack of data often leads medical device manufacturers to be reactive rather than proactive to problems, which can affect the quality of patient care in the long term. Summary of the Invention [Means for solving the problem]

[0005] Disclosed herein is a digital communications module ("DCM") for the transmission of data from a medical device. An exemplary DCM is positioned between the medical device's processor (or therapy module) and a 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 contained within or integrated with the medical device. The DCM disclosed herein is configured as a gateway (such as an Internet of Things ("IoT") gateway) for parallel or simultaneous transmission of medical device data to the medical network and an external server separate from the medical network (e.g., a medical device manufacturer server using IoT shadow services).

[0006] In an embodiment, the DCM receives medical device data from a medical device processor or therapy module. The DCM is configured to transmit two separate streams of medical device data to a medical network. For the first data stream, the DCM provides the medical device data in a first format for transmission to an external server, which may be operated by the device manufacturer of the corresponding 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 cases, the DCM may anonymize the medical device data for the first data stream and add log / health data, which is of interest to the device manufacturer and enables advanced analytics to evaluate the operation of the medical device. For the second data stream, the DCM transmits the medical device data along with patient-identifying information for inclusion in an appropriate EMR or for use by an appropriate hospital system. DCM accordingly 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 they previously use internally (thereby not requiring any changes to the medical network).

[0007] The exemplary DCM disclosed herein may be remotely configured via a configuration file. The exemplary file allows an operator to specify the medical device type, the hardware interface for connection to the medical device, the device driver for data management, the data transmission type, and the hardware interface for data transmission. After receiving the configuration file, the DCM is configured to install the specified drivers and configure the specified input and output interfaces to seamlessly integrate the medical device with the medical network. The configuration file may be updated to change connectivity requirements and / or data formats after the DCM is deployed at the hospital site, providing flexibility to device manufacturers.

[0008] An exemplary DCM operates with any type of medical device. For example, a DCM may operate with medical devices for plasma exchange, hemodialysis ("HD"), hemofiltration ("HF"), hemodiafiltration ("HDF"), and continuous renal replacement therapy ("CRRT") treatments. The DCM described herein may also operate with medical devices for peritoneal dialysis ("PD"), intravenous drug delivery, and nutritional fluid delivery. These different treatment modalities may be referred to herein collectively, generally, or individually as medical fluid delivery or treatment.

[0009] The above modalities may be provided by a medical fluid delivery machine that houses the components needed to deliver medical fluids, such as one or more pumps, valves, heaters (if needed), direct medical fluid generators (if needed), sensors such as pressure sensors, conductivity sensors, temperature sensors, air detectors, blood leak detectors, and the like, a user interface, and a control unit that may employ one or more processors and memory for controlling the above-described 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, dialysis fluid, or other fluids.

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

[0011] As described in detail below, the DCM of the present disclosure may operate within a comprehensive platform system that may include many machines with many different types of devices, patients, clinicians, physicians, maintenance 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 entire system without violating its rules and protocols.

[0012] In a first aspect of the present disclosure, which may be combined with any other aspects recited herein in light of the disclosure herein and without limiting the disclosure in any way, a digital communication device includes an input interface configured for communicative coupling to a medical device and an output interface configured for communicative coupling to 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 at least one configuration file and drivers for the input and output ports. 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 defining 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 the memory device, install drivers for the input and output ports defined by the configuration file, provision an input interface with the defined input port to receive medical data from the medical device in a first data format, and provision an output interface with at least one defined output port to transmit at least a portion of the received medical data using the first data format and a second data format.

[0013] In a second aspect of the present disclosure, which may be combined with any other aspects enumerated herein, a processor is configured to receive medical data in a first format from a medical device via an input interface, select a first subset of the medical data for transmission in the first data format via the output interface via one of the output ports as defined by a configuration file, convert a second subset of the medical data to a second data format, and transmit the second subset of the medical data in the second data format for transmission via the same or a different output port as defined by the configuration file.

[0014] In a third aspect of the present disclosure, which may be combined with any other aspects enumerated herein, the first subset of medical data is identical to the second subset of medical data.

[0015] In a fourth aspect of the present disclosure, which may be combined with any other aspects enumerated herein, the output interface provides a communication coupling to 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 the medical data in a second data format to at least one of the EMR server, the middleware server, or the integration engine using the same or a different output port as defined by a configuration file.

[0016] In a fifth aspect of the present disclosure, which may be combined with any other aspects enumerated herein, at least one of the Ethernet port and the wireless port provides a communication coupling to a remote server outside the medical network, and the processor is configured to transmit a first subset of the medical data in a first data format to the remote server using the at least one of the Ethernet port or the wireless port.

[0017] In a sixth aspect of the present disclosure, which may be combined with any other aspect enumerated herein, a processor includes a first connectivity agent and uses a messaging protocol for transmission of a first subset of medical data in a first data format.

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

[0019] In an eighth aspect of the present disclosure, which may be combined with any other aspects enumerated herein, a configuration file specifies a first destination network address to receive a first subset of medical data in a first data format and a second destination network address to receive a second subset of medical data in a second data format, the first destination network address being associated with a network domain outside the medical network and the second destination network address being associated with a network domain that includes the medical network.

[0020] In a ninth aspect of the present disclosure, which may be combined with any other aspects enumerated herein, a processor is configured to generate log data and health data, include the log data and health data together with a first subset of medical data for transmission in a first data format via an output interface via one of the output ports as specified by a configuration file, convert the log data to a second data format, and include the log data together with a second subset of medical data for transmission via the same or a different output port as specified by the configuration file.

[0021] In a tenth aspect of the present disclosure, which may be combined with any other aspects enumerated herein, the log data includes at least one of an identification of a medical device type, an identification of a medical device serial number, a timestamp at which medical data received therefrom was generated by the medical device or received by the processor from the medical device, an apparatus identifier, a timestamp for the first subset of medical data, or a monotonic timestamp, and the health information includes information related to the medical device, CPU usage information, network connectivity information, process / thread information, or information related to software operated by the processor to process the first and second subsets of medical data for transmission.

[0022] In an eleventh aspect of the present disclosure, which may be combined with any other aspects enumerated herein, the processor is configured to at least one of anonymize patient information included in a first subset of the medical data prior to transmission or encrypt the first subset of the medical data prior to transmission.

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

[0024] In a thirteenth aspect of the present disclosure that may be combined with any other aspect enumerated herein, the periodic interval has a period of 5 seconds to 60 seconds.

[0025] In a fourteenth aspect of the present disclosure, which may be combined with any other aspects enumerated herein, the processor is configured to use event tracking to identify changes in medical data between snapshots, and to include only medical data that has changed from the previous snapshot as at least one of the first subset of medical data or the second subset of medical data.

[0026] In a fifteenth aspect of the present disclosure, which may be combined with any other aspect enumerated herein, a configuration file specifies a type of medical device and specifies that medical data to be received from the medical device is provided in a first data format.

[0027] In a sixteenth aspect of the present disclosure, which may be combined with any other aspect enumerated 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 purification machine, or a nutrient preparation machine.

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

[0029] In an eighteenth aspect of the present disclosure, which may be combined with any other aspect enumerated herein, the second data format includes a Health-Level 7 (“HL7”) protocol, a Rapid Healthcare Interoperability Resources (“FHIR”) protocol, or a binary protocol.

[0030] In a nineteenth aspect of the present disclosure, which may be combined with any other aspect enumerated herein, 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.

[0031] In a twentieth aspect of the present disclosure, which may be combined with any other aspects enumerated herein, the medical data includes at least one of event information comprising transitions between fill, dwell, and drain phases of a dialysis cycle, alarm information, therapy programming information, or therapy information comprising estimated fill rate, drain rate, and amount of ultrafiltration removed.

[0032] In a twenty-first aspect of the present disclosure, any of the structures and functionality disclosed in connection with Figures 1-9 may be combined with any of the other structures and functionality disclosed in connection with Figures 1-9.

[0033] In light of the present disclosure and the above aspects, it is therefore an advantage of the present disclosure to provide an improved system for communicating medical device data to medical device manufacturers.

[0034] It is another advantage of the present disclosure that configuration files are used to configure drivers and / or hardware interfaces that reside on the DCM.

[0035] Additional features and advantages will be described in, and will be apparent from, the following detailed description and figures. The features and advantages described herein are not all-inclusive; in particular, many additional features and advantages will become apparent to those skilled in the art in view of the figures and description. Moreover, it is not necessary for any particular embodiment to have all of the advantages enumerated herein; it is expressly contemplated that each advantageous embodiment may be separately claimed. It should also be noted that the language used herein has been chosen primarily for purposes of readability and instruction, and not to limit the scope of the inventive subject matter. The present invention provides, for example, the following. (Item 1) 1. A digital communication device, comprising: an input interface configured for communicative coupling to 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 communicative coupling to 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 drivers for said input and output ports; a processor communicatively coupled to the input interface, the output interface, and the memory device, the processor comprising: receiving a configuration file from a management computer via the output interface, the configuration file defining 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; storing said configuration file in said memory device; installing drivers for the input and output ports defined by the configuration file; provisioning the input interface with the defined input port to receive medical data from the medical device in the first data format; provisioning the output interface with the at least one defined output port for transmitting at least a portion of the received medical data using the first data format and the second data format; a processor configured to: An apparatus comprising: (Item 2) The processor is receiving the medical data in the first format from the medical device via the input interface; selecting a first subset of the medical data for transmission in the first data format via the output interface through one of the output ports as defined by the configuration file; converting a second subset of the medical data into the second data format; transmitting a second subset of said medical data in said second data format for transmission via the same or a different output port as defined by said configuration file; Item 1. The device according to item 1, configured to perform the following: (Item 3) Item 3. The apparatus of item 2, wherein the first subset of medical data is identical to the second subset of medical data. (Item 4) the output interface provides a communicative coupling to at least one of an electronic medical record ("EMR") server, a middleware server, or an integration engine via the medical network; the processor is configured to transmit a second subset of the medical data in the second data format to at least one of the EMR server, the middleware server, or the integration engine using the same or a different output port as defined by the configuration file; Item 2 or 3. The device according to item 2 or 3. (Item 5) at least one of the Ethernet port and the wireless port provides a communications coupling to a remote server external to the medical network; the processor is configured to transmit a first subset of the medical data in the first data format to the remote server using at least one of the Ethernet port or the wireless port; Item 2 or 4. The device according to item 2 or 4. (Item 6) 6. The apparatus of claim 2, 4, or 5, wherein the processor includes a first connectivity agent and uses a messaging protocol for transmission of the first subset of the medical data in the first data format. (Item 7) Item 7. The apparatus of item 6, wherein the messaging protocol includes a Message Queuing Telemetry Transport ("MQTT") publish-subscribe network protocol. (Item 8) the configuration file defines a first destination network address to receive a first subset of the medical data in the first data format and a second destination network address to receive a second subset of the medical data in the second data format; the first destination network address is associated with a network domain external to the medical network, and the second destination network address is associated with a network domain including the medical network; 6. The device according to item 2, 4, or 5. (Item 9) The processor is generating log data and health data; including the log data and the health data with a first subset of the medical data for transmission in the first data format via the output interface via one of the output ports as defined by the configuration file; converting the log data into the second data format; including the log data with a second subset of the medical data for transmission via the same or a different output port as defined by the configuration file; and 9. The apparatus of item 2, 4, or 8, configured to perform (Item 10) The log data includes at least one of an identification of a medical device type, an identification of a medical device serial number, a timestamp at which the received medical data was generated by the medical device or received by the processor from the medical device, an identifier of the device, a timestamp for a first subset of the medical data, or a monotonic timestamp; the health information includes information related to the medical device, CPU usage information, network connectivity information, process / thread information, or information related to software operated by the processor to process the first and second subsets of the medical data for transmission; Item 9. The device according to item 9. (Item 11) The processor is de-identifying the patient information contained in the first subset of medical data prior to transmission; or encrypting the first subset of said medical data prior to transmission; 11. The apparatus of item 2, 9, or 10, configured to perform at least one of the following: (Item 12) The processor is receiving the stream of medical data; taking snapshots of said medical data at periodic intervals; providing the snapshot of the medical data as at least one of the first subset of the medical data or the second subset of the medical data; 12. The apparatus according to item 2 or 11, configured to perform (Item 13) Item 13. The device according to item 12, wherein the periodic interval has a period of 5 seconds to 60 seconds. (Item 14) The processor is using event tracking to identify changes in said medical data between snapshots; including only medical data that has changed since a previous snapshot as at least one of the first subset of medical data or the second subset of medical data; Item 13. The apparatus according to item 12, configured to perform the following: (Item 15) 13. The apparatus of claim 1 or 12, wherein the configuration file specifies the type of the medical device and specifies that the medical data to be received from the medical device is provided in the first data format. (Item 16) 16. The apparatus of claim 1, 12, or 15, wherein 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 purification machine, or a nutrient preparation machine. (Item 17) 17. The apparatus of claim 1, 12, or 16, wherein the first data format includes JavaScript Object Notation ("JSON"), Hypertext Transfer Protocol ("HTTP"), or a binary protocol. (Item 18) 18. The apparatus of claim 1, 12, or 17, wherein the second data format comprises a Health-Level 7 ("HL7") protocol, a Rapid Healthcare Interoperability Resources ("FHIR") protocol, or a binary protocol. (Item 19) Item 1, 12, or 18. The device of item 1, 12, or 18, 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. (Item 20) The above medical data Event information comprising transitions between fill, dwell, and drain phases of a dialysis cycle; Alarm information, Treatment programming information, or Treatment information with estimated fill rate, drainage rate, and amount of ultrafiltration removed 20. The device of item 1, 12, or 19, comprising at least one of: [Brief explanation of the drawings]

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

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

[0038] [Figure 3] FIG. 3 is a schematic diagram of the exemplary DCM of FIGS. 1 and 2, according to an exemplary embodiment of the present disclosure.

[0039] [Figure 4] 4 and 5 are diagrams illustrating how configuration files are installed on the DCM of FIGS. 1-3, according to an exemplary embodiment of the present disclosure. [Figure 5] 4 and 5 are diagrams illustrating how configuration files are installed on the DCM of FIGS. 1-3, according to an exemplary embodiment of the present disclosure.

[0040] [Figure 6] FIG. 6 is a diagram illustrating the configuration files of FIGS. 4 and 5, according to an exemplary embodiment of the present disclosure.

[0041] [Figure 7] FIG. 7 is a schematic diagram of the DCM of FIGS. 1-3 including an input port, an output port, and a processor including one or more applications described above in connection with FIG. 3 for processing medical device data, according to an exemplary embodiment of the present disclosure.

[0042] [Figure 8]FIG. 8 is a flow diagram of an exemplary procedure for configuring the DCM of FIGS. 1-5 and 7 using a configuration file, according to an exemplary embodiment of the present disclosure.

[0043] [Figure 9] FIG. 9 is a flow diagram of an example procedure for processing medical device data using the DCM of FIGS. 1-5 and 7, according to an example embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0044] Detailed Description A digital communications module ("DCM") for the transmission of data from a medical device is disclosed. The exemplary DCM is configured to receive medical device data from a medical device. The DCM transmits the medical device data in parallel to a local hospital network and an external server (such as a medical device manufacturer's server). In some embodiments, the DCM anonymizes 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. Additionally, in some embodiments, the DCM may convert the medical device data into a different format for the hospital system. The exemplary DCM is provisioned via a configuration file that specifies input interface parameters, output interface parameters, device driver parameters, and / or data conversion parameters. After receiving the configuration file, the DCM is configured to install the specified device drivers and provision the data conversion / encryption mechanisms as well as provision the specified input / output interfaces.

[0045] The DCM is configured to operate with many different types of medical devices and communicate via different types of interfaces, such as serial connections (e.g., RS-232 or RS-485 connections), Ethernet connections, Wi-Fi connections, Bluetooth connections, and / or universal serial bus ("USB") connections. 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, nutrition compounding machines, infusion pumps, etc. Furthermore, the configurability of the DCM allows for its use within differently configured hospital systems. The configurability of the DCM accordingly allows medical device data to be transmitted to an external server without the need to make connectivity or networking changes to the medical devices or hospital systems.

[0046] Medical device data is referred to herein. As disclosed, medical device data (e.g., medical data) is generated in the medical device and transmitted to the DCM. The medical device data includes therapy programming information, which comprises one or more parameters that define how the medical device should operate to administer therapy to the patient. For peritoneal dialysis therapy, the 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 should remain in the patient's peritoneal cavity (i.e., dwell time), and the amount (or rate) of spent dialysis fluid and ultrafiltration ("UF") to be pumped or drained from the patient after the dwell cycle ends. For therapy involving multiple cycles, the parameters may specify the fill, dwell, and drain per cycle and the total number of cycles to be performed during the course of therapy (one therapy provided per day, or separate therapy provided during the day and night). Additionally, the parameters may specify the date / time / day (e.g., schedule) on which the therapy should be administered by the medical fluid delivery machine. Additionally, the parameters of the prescribed therapy may define the total volume of dialysis fluid to be administered per treatment, as well as the concentration level of the dialysis fluid, such as glucose level. With respect to infusion therapy, the parameters may include the volume to be infused, the drug to be infused, the drug concentration, the drug dosage, and / or the infusion rate.

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

[0048] Medical device data further includes device mechanical logs, including 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 provided at periodic intervals. In some cases, medical device data may be transmitted when an event or other change in data occurs.

[0049] Log data and health data generated by an exemplary DCM are also referred to herein. Log data includes identification of the therapy (medical) device type, identification of the therapy device serial number, timestamps from which therapy data was generated or received from the therapy device, an identifier of the DCM, timestamps for snapshots, and / or monotonic timestamps for the DCM. 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 embedded software applications.

[0050] While the following illustrates a DCM partitioning medical device data into two separate data streams or subsets, it should be understood that the DCM may partition the data into three or more separate streams. In some examples, each different stream may be directed to a different destination, contain a different data format, and / or contain a different subset of medical device data and / or log / health data. In addition to the manufacturer's analytics server, medical device data may be provided to a pharmaceutical / dialysis fluid manufacturer's data analytics server, a continuous quality improvement system, auditors, regulatory authorities, etc. I. DCM environment implementation example

[0051] 1 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 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.

[0052] In the exemplary embodiment, DCM 102 is configured to receive only medical device data from medical device 104. This unidirectional communication configuration prevents another device from being able to access, program, or otherwise communicate with medical device 104 through DCM 102. However, in some embodiments, DCM 102 may have a bidirectional communication link with medical device 104 to allow data, programming 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 environment 100 may include tens to hundreds, or even thousands, of medical devices and individual DCMs.

[0053] The exemplary medical device 104 is configured to accept one or more parameters that define 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 there is a change in the data. New medical device data written to the log files is transmitted to the DCM 102. In some embodiments, the medical device 104 produces 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.

[0054] The exemplary medical device 104 may include one or more control interfaces 105 to display instructions and receive control inputs 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 certain 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.

[0055] 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 administer a therapy to the patient. The instructions may be obtained via the control interface 105. The processor or therapy module 107 also monitors the device components for problems, which are documented as diagnostic information. The processor or therapy module 107 generates medical device data in conjunction with operating one or more pumps or other components to administer a therapy. The processor or therapy module 107 transmits the medical device data to the DCM 102.

[0056] 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 appliances to establish communication connections and route data. The medical network 106 may also include one or more firewalls that limit access to only authorized remote devices and / or servers. The medical network 106 may include any local area network ("LAN"), Ethernet network, Wi-Fi network, or combination thereof.

[0057] 1, the DCM 102 may be wired or wirelessly coupled to the medical network 106. 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.

[0058] FIG. 2 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 a medical device 104. The DCM 102 may include, for example, a Digi ConnectCore® 6UL module with an NXP i.MX6UL-2, Cortex-A7 528 MHz CPU, and a 256 MB / 1 GB NAND and 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 a Yocto Linux® operating system and contains drivers for the Digi chipset.

[0059] 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 an individual patient. The EMR server 108 may store medical device data in HL7 format, binary version 2 format, binary version 3 format, or Rapid Healthcare Interoperability Resources (“FHIR”) format.

[0060] The exemplary DCM environment 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 DCM environment 100 may also include a middleware system and / or an integration engine. The DCM environment 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 medical device 112.

[0061] The example DCM environment 100 of FIG. 1 also includes an external network 120 that is communicatively coupled to an analytics server 122. The external network 120 may include any routers, gateways, switches, cellular towers, and / or network appliances 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. The medical network 106 may be assigned a domain or subdomain address that is recognized 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 and instead couple to the cellular network of the external network 120.

[0062] The exemplary analysis server 122 is configured to receive at least some medical device data from the DCM 102. The analysis server 122 stores the received data in a memory device 124, which may include any device configured for persistent storage of data. The memory device 124 operates with the analysis server 122 to store the medical device data through a Platform as a Service ("PaaS") framework via Amazon Web Services® ("AWS"). In other embodiments, the memory device 124 may be configured to store the medical device data in a Structured Query Language ("SQL") database, a NoSQL database, Amazon® Relational Database Service ("RDS"), or the like. The analysis server 122 may include one or more application programming interfaces ("APIs") configured to receive the medical device data from the DCM 102. The APIs may be connected to ports on the analysis server 122 that are assigned one or more destination Internet Protocol ("IP") addresses. The DCM 102 is configured with one or more destination IP addresses to enable transmission of medical device data to the analysis server 122 .

[0063] The analysis server 122 is configured to periodically analyze the received medical device data for certain key performance indicators (“KPIs”) related to the operation of the medical device 104. The KPIs may relate to treatment trends, component (e.g., pump or filter) usage, alert / alarm trends, etc. The analysis server 122 may analyze the medical device data and determine recommendations and / or guidelines for improving the operation of the medical device 104 and / or improving treatment protocols for certain disease conditions. For example, the analysis server 122 may determine more optimal peritoneal dialysis programming parameters for a patient with some degree of renal failure. Analysis of the medical device data may include the analysis server 122 providing normalization, analysis of DCM device logs, and analysis of DCM health statistics.

[0064] 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 nutrient preparation machine, 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.

[0065] Regarding renal failure therapy, due to various causes, a patient's renal system may fail. Renal failure results in several physiological disturbances. For example, a patient suffering from renal failure can no longer maintain fluid and mineral balance or excrete daily metabolic loads. Toxic end products of nitrogen metabolism (urea, creatinine, uric acid, and others) can accumulate in the patient's blood and tissues. Renal failure and reduced kidney function are treated using dialysis. Dialysis removes waste products, toxins, and excess water from the body that normally functioning kidneys would otherwise remove. Dialysis therapy for kidney function replacement is important for many people because the treatment is lifesaving.

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

[0067] Hemofiltration ("HF") is an alternative renal replacement therapy that relies on convective transport of toxins from the patient's blood. HF is accomplished by adding replacement or replacement fluid (typically 10–90 liters of such fluid) to the extracorporeal circuit during treatment. The replacement fluid and the fluid accumulated by the patient during treatment are ultrafiltered over the course of HF treatment, providing a convective transport mechanism that is particularly beneficial in removing medium and large molecules. (In hemodialysis, small amounts of waste products are removed with the fluid obtained during the dialysis session; however, the solute drag from the removal of the ultrafiltrate is not sufficient to provide convective clearance.)

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

[0069] Another type of kidney failure therapy is peritoneal dialysis, in which a dialysate, also called dialysis fluid, is infused into a patient's peritoneal cavity via a catheter. The dialysis fluid contacts the peritoneal membrane of the cavity. Waste, toxins, and excess water pass from the patient's bloodstream, through the peritoneal membrane, and into the dialysis fluid due to diffusion and osmosis; an osmotic gradient occurs across the membrane. An osmotic agent in dialysis provides the osmotic gradient. Spent or depleted dialysis fluid 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.

[0070] Various types of peritoneal dialysis therapies exist, including continuous ambulatory peritoneal dialysis ("CAPD"), automated peritoneal dialysis ("APD"), and tidal flow dialysis, and continuous flow peritoneal dialysis ("CFPD"). CAPD is a manual dialysis treatment. Here, the patient manually connects an implanted catheter to a drain to allow spent or spent dialysate fluid to drain from the peritoneal cavity. The patient then connects the catheter to a bag of fresh dialysis fluid to infuse fresh dialysis fluid into the patient through the catheter. The patient disconnects the catheter from the fresh dialysis fluid bag and allows the dialysis fluid to dwell in the peritoneal cavity, where transfer of waste, toxins, and excess water occurs. After a dwell period, the patient repeats the manual dialysis procedure, for example, four times per day, with each treatment lasting approximately one hour. Manual peritoneal dialysis requires a significant amount of time and effort from the patient and leaves room for improvement.

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

[0072] APD machines pump spent or depleted dialysate from the peritoneal cavity, through the catheter, and to a drain. As with the manual process, several drain, fill, and dwell cycles occur during dialysis. A "final fill" occurs at the end of APD, and the fluid remains in the patient's peritoneal cavity until the next treatment. II. DCM embodiment

[0073] 3 is a schematic 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 device manager 302 configured to generate two parallel data streams of medical device data received from the medical devices 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. With respect to a first data stream or subset provided to the analysis server 122, the DCM 102 includes an external agent 310, an external interface 312, and an external persistent storage device 314. With respect to a second data stream or subset provided to the EMR server 108, the DCM 102 includes an internal agent 320, an internal interface 322, and an internal persistent storage device 324.

[0074] The example components 302-312, 320, and 322 of the DCM may be implemented using one or more computer programs or applications. The programs or applications 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 disks, optical memory, or other storage medium. The instructions may be configured to be executed by a processor of the DCM 102, which, upon executing the series of computer instructions, performs or facilitates the performance of all or a portion of the disclosed methods and procedures disclosed herein. The persistent storage devices 314 and 324 may include any memory device, including RAM, ROM, flash memory, etc.

[0075] The example data device manager 302 is configured to interface with the 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 points in time. The time periods are defined by a configuration file (such as configuration file 342) and may include, for example, 5-second intervals, 10-second intervals, 30-second intervals, 60-second intervals, etc. For each snapshot, the data device manager 302 reads the most recently received data from the medical device 104. In this manner, the device data manager 302 provides periodic updates regarding the status of the medical device 104.

[0076] In some embodiments, the medical device 104 may transmit medical device data 330 in a continuous stream, at periodic intervals, or after a change in the data. The medical device 104 may transmit medical device data 330 in a log file or a stream of messages. The device data manager 302 compiles the data received since the last snapshot interval. As the next interval approaches, the device data manager 302 compiles the most recent data into a snapshot, providing a representation of the medical device 104 at that time. If multiple events occur during a compilation period, the device data manager 302 may include only the most recent event or all of the events that occurred during the time period.

[0077] In some instances, the device data manager 302 may compare the current snapshot with a previous snapshot. Based on the comparison, the device data manager 302 may include only medical device data in the current snapshot that has changed since the previous snapshot. The comparison reduces the amount of data transmitted in each snapshot so that only new and / or updated medical device data 330 is communicated. For example, a CRRT medical device 104 may continuously transmit an estimated UF removal value, which typically does not change during the fill and dwell cycles of PD therapy. Thus, the device data manager 302 only includes UF removal values ​​when there is a change in value. In another example, an alarm may activate at a certain time. A device status indicating that the alarm is still active may be included in the medical device data 330. However, the device data manager 302 only includes a notification in the first snapshot of the time (and alarm type) the alarm activates and the time the alarm was dismissed or reset in the second, subsequent snapshot, without including an indication that the alarm was active in the intermediate snapshots.

[0078] 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 these cases, the device data manager 302 writes the received medical device data 302 to the appropriate snapshot.

[0079] In conjunction with creating snapshots of the medical device data 330, the example device data manager 302 creates two separate data sets or streams. The first data set or stream 316 is associated with the analytics server 122. The second data subset or stream 326 is associated with the EMR server 108 and / or the hospital system 110. The first data stream or subset 316 may include medical device data 330 from the same snapshot as the second data stream or subset 326. In other embodiments, the first data stream or subset 316 may include medical device data 330 from additional or fewer snapshots compared to the second data stream or subset 326. For example, the device data manager 302 may be configured to include diagnostic data (identified by metadata, data field indicators, location, etc.) in the first data stream or subset 316, but not include diagnostic data in the second data stream or subset 326. Additionally, the device manager 302 may include patient identification data in the second data stream or subset 326 while not including any patient identification data in the first data stream or subset 316 .

[0080] The example DCM 102 includes an external agent 310 for anonymizing the first data stream or subset 316 and generating an anonymized first data stream or subset 318. The external agent 310 may be configured to search for data indicators or keywords indicative of patient names, hospital-assigned identifiers, social security numbers, etc. In some instances, patient-specific information may be replaced with a (randomly) generated session identifier used by the analytics server 122 to associate medical device data from the same treatment. In other embodiments, patient-identifying information is removed or deleted by the external agent 310.

[0081] The example external agent 310 is also configured to combine the log and / or health data 319 with the de-identified first data stream or subset 318 or include the log and / or health data 319 along with the de-identified first data stream or subset 318. The log data is generated by the log manager 304 and includes a medical device type identification, a medical device serial number identification, a timestamp from which the medical device data 330 was generated or received from the medical device 104, an identifier of the DCM 102, a timestamp for a snapshot created by the device data manager 302, and a monotonic timestamp of the DCM. The medical device type identification, medical device serial number identification, and DCM 102 identifier may be specified in a configuration file 342. In some instances, the medical device type identification and medical device serial number identification may be reported by the medical device 104. The log manager 304 is configured to store this information and create appropriate timestamps when the medical device data 330 is received and / or snapshots are created. The log manager 304 then transmits the log data to the external agent 310 for each snapshot, which corresponds to the anonymized first data stream or subset 318 that is transmitted to the analytic server 122 .

[0082] The example system health manager 306 is configured to obtain and / or determine health information that is relayed to the DCM 102. The system health manager 306 is configured to transmit to the external agent 310 DCM system memory information (associated with persistent storage devices 314 and 324), DCM CPU usage information, network connectivity information, process / thread information, and / or information related to one or more software applications running on the DCM 102. To obtain this information, the system health manager 306 is configured to access and / or read memory usage information of the persistent storage devices 314 and 324. Additionally, the system health manager 306 is configured to monitor one or more processors of the DCM 102 that implement the operations described herein. The system health monitor 306 also monitors network connectivity and / or detects loss of network connectivity via a lack of receipt of an acknowledgment message at the analysis server 122 and / or the EMR server 108. Similar to the log manager 304, the system health manager 306 transmits health information to the external agent 310 for transmission with the anonymized first data stream or subset 318. In some instances, a configuration file 342 may specify information to be obtained by the system health monitor 306 and / or specify health information to be provided to the external agent 310 and / or internal agent 320.

[0083] The example external agent 310 configures the anonymized first data stream or subset 318 and / or log / health data 319 for transmission to the analysis server 122. The external agent 310 receives a destination IP address of the analysis server 122 from the configuration file 342. The external agent 310 may also receive domain connectivity information for the medical network 106 and / or API connection information for the analysis server 122 from the configuration file 342. The external agent 310 uses the destination address and networking domain information provided by the configuration file 342 to create one or more messages with the anonymized first data stream or subset 318 and / or log / health data 319 for transmission to the analysis server 122.

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

[0085] In some embodiments, the external interface 312 (and / or the internal interface 322) is configured to use MQ Telemetry Transport ("MQTT") to transmit messages with the anonymized first data stream or subset 318 and / or log / health data 319 to the analytics server 122. In this case, the external interface 312 is configured as a publisher, and the analytics server 122 is configured as a broker. In other examples, the internal interface 312 (and / or the internal interface 322) may be configured to communicate using Minimal Lower Layer Protocol ("MLLP").

[0086] In some instances, the example external interface 312 is configured to determine whether an active connection to the analysis server 122 exists. The external interface 312 may transmit periodic pings to the analysis server 122 and determine the network status based on the response to the ping. In other examples, the external interface 312 may determine whether an acknowledgment message is received in response to transmitting a snapshot of the anonymized first data stream or subset 318 and / or log / health data 319. If an acknowledgment message is not received within a defined threshold, the external interface 312 determines that a loss of network connectivity with the analysis server 122 has occurred. After determining that no connection to the analysis server 122 exists, the external interface 312 is configured to store an encrypted message containing the anonymized first data stream or subset 318 and / or log / health data 319 in the external persistent memory device 314. The external interface 312 stores subsequent snapshots of messages containing the anonymized first data stream or subset 318 and / or log / health data 319 in the memory device 314 until a network connection is re-established, at which point the external interface 312 transmits all of the messages stored in the memory device 314 to the analytics server 122.

[0087] In some instances, a connection with the analytics server 122 is not established. In these examples, the external interface 312 is configured to store the anonymized first data stream or subset 318 and / or log / health data 319 in the memory device 314 until the data can be manually retrieved by an operator by connecting a computer or USB memory device to the DCM 102. The external interface 312 may be configured by the configuration file 342 to store the data for a specified number of hours or days. After the specified number of hours or days has passed, the external interface 312 may overwrite the oldest data with newly received data.

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

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

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

[0091] 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 into a data format compatible with or required by the EMR server 108. In other words, the internal agent creates a transformation of the second data stream or subset 328 and / or log data 319. The transformation type may be specified by a configuration file 342. The transformation may 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 specify how the second data stream or subset 326 and / or log data 319 in JSON format should be transformed to HL7, binary, and / or FHIR, for example. The files and / or algorithms may identify the JSON data by location, data indicator, field name, and / or metadata and specify how the data should be transformed, including transforming data indicator names, metadata names, numeric formats, positioning, etc. The internal agent 320 then transmits the transformed second data stream or subset 328 and / or the log data 319 to the internal interface 322 .

[0092] The example internal interface 322 is configured to check for a connection to the EMR server 108 in a manner similar to how the external interface 312 checks for a connection with the analysis server 122. Additionally, for a serial connection, the internal interface 322 may check for the presence of a serial connector into a port of the DCM 102. If a connection does not exist, the internal interface 322 stores the transformed second data stream or subset 328 and / or log data 319 in the internal persistent memory device 324. If a connection does exist, the internal interface 322 transmits one or more messages with the second data stream or subset 328 and / or log data 319 to the EMR server 108 (including any previously stored messages in the memory device 324 with a previous snapshot of the second data stream or subset 326 and / or log data 319). In some embodiments, the internal interface 322 may encrypt messages (for non-serial connections) that accompany the transformed second data stream or subset 328 and / or the log data 319 if the EMR server 108 supports the transformation.

[0093] 3 also includes a configuration file manager 350 for storing and / or processing one or more configuration files 342. Configuration file manager 350 is configured to receive configuration files 342 from computer 400 or server 500, as discussed below in connection with FIGS.

[0094] The configuration file manager 350 reads the configuration file 342 and configures the log manager 304, the system health manager 306, the device data manager 302, the external agent 310, the external interface 312, the internal agent 320, and / or the internal interface 322 as specified in the file 342. With respect to the log manager 304, this may include writing the DCM identifier, medical device type, medical device identifier, etc. to registers, parameters, and / or variables of the log manager 304. With respect to the system health manager 306, this may include specifying parameters / attributes of the memory devices 314, 324 and / or processor / CPU of the DCM 102 to monitor. With respect to the internal agent 320, this may include specifying data types for conversion.

[0095] In some instances, the configuration file manager 350 may also define conversion file types for the external agent 310. Additionally, 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 the separate streams and / or subsets 316, 326, and / or 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 define network credentials, authentication information, encryption keys, API identifiers, destination IP addresses, etc. for the external interface 312 and internal interface 322.

[0096] Configuration file manager 350 may also define or otherwise provide a user interface that allows a user of computer 600 or server 700 to view and / or modify stored configuration files 342. The user interface may include fields for configuring network connectivity for DCM 102, defining an identifier for DCM 102, defining a username / password for accessing DCM 102, defining parameters for configuration file 342, and / or installing software such as a connectivity client or application.

[0097] 4 is a diagram showing the configuration file 342 of FIG. 3 being installed on the DCM 102 via a computer 400, according to an exemplary embodiment of the present disclosure. In this example, the computer 400 connects directly to the DCM 102 via an Ethernet, serial, or USB connection. The computer 400 may be operated by a hospital technician or a technician associated with the manufacturer of the medical device 104.

[0098] After connecting, DCM 102 invokes an interface for display on computer 400 via configuration file manager 350. During this time, an operator of computer 400 may edit and / or enter information into fields in the user interface related to configuration, network, software, and / or security. Additionally, computer 400 is configured to allow the operator, via configuration file manager 350, to define parameters or attributes of configuration file 342. After the parameters and / or attributes are defined, computer 400 transmits configuration file 342 to DCM 102. Configuration manager 350 receives configuration file 342 and provisions or otherwise configures DCM 102 accordingly.

[0099] 5 shows a schematic diagram of a server 500 installing a configuration file 342 on a DCM 102. In this example, the DCM 102 may be configured with the server's 500 IP address at the time of manufacture. The DCM 102 may also be configured with information related to the medical device 104, such as authentication information for accessing the medical network 106, network settings, and / or device type. After the DCM 102 is powered on, the DCM 102 transmits a request message to the server 500 requesting the configuration file 342. The request message may include authentication and / or validation information and / or the IP address of the DCM 102. The server 500 may store one or more different types of configuration files based on hospital network and / or local configuration preferences. The server 500 determines the configuration file to be assigned to the DCM 102 based, for example, on the type of medical device 104, the medical network 106, etc.

[0100] In response, after verification, the server 500 transmits the selected configuration file 342 to the DCM 102 via the external network 120 and the medical network 106. The DCM 102 receives the configuration file 342, which is used by the configuration file manager 350 of FIG. 3 to provision or otherwise configure the DCM 102. The configuration shown in FIG. 5 allows for automatic configuration of the DCM 102 without a direct connection to a technician or computer. In some embodiments, the server 500 may include the analysis server 122 of FIGS. 1-3.

[0101] 6 shows a diagram illustrating parameters and / or attributes of a configuration file 342 selectable by an operator at the computer 400 of FIG. 4 or defined by the server 500 of FIG. 5 according to an exemplary embodiment of the present disclosure. The configuration file 342 includes parameters related to a medical device type 602. Selection of a medical device type provides an indication of the type and / or format of medical device data to be received. Selection of a medical device type parameter 602 may also cause the DCM 102 to install one or more drivers for processing data from that medical device type. It should be understood that drivers may be stored on the DCM 102 and installed only when the corresponding device type parameter is selected.

[0102] The configuration file 342 also includes an input port type parameter 620. Selection of the input port type parameter 620 provides an indication as to which input port of the DCM 102 should be provisioned and / or activated. The DCM 102 may also install one or more drivers for the selected input port that define how data from the medical device is converted, for example, to a standardized JSON format. The configuration file 342 further includes parameters for the external interface 630 and parameters for the internal interface 640, including a data conversion type, a connection protocol, and / or an encryption data protection protocol. This also includes a selection of one or more hardware output ports of the DCM 102 that should be provisioned and / or activated.

[0103] The configuration file 342 further includes parameters for DCM information 650, such as identification information, IP or network address, snapshot period, memory device persistence information, health statistics to monitor, etc. The DCM information parameters 650 may also include an external address and / or authentication information for accessing the analysis server 122 and an internal address and / or authentication information for accessing the EMR server 108.

[0104] In some embodiments, the configuration file manager 350 may display an interface similar to the parameters shown in FIG. 6. A user may select parameters by simply selecting the corresponding button or typing information into the displayed field. In other embodiments, the configuration file is text-based, XML-based, and / or JSON-based, and parameters may be defined in a section of the file or identified by associated data indicators / fields. It should be appreciated that the configuration file 342 enables data transmission from virtually any medical device type to an external server in any desired format without the need to make modifications to the medical device or network infrastructure.

[0105] 7 is a schematic diagram of a DCM 102 including an input port 702, an output port 704, and a processor 706 including one or more applications described above in connection with FIG. 3 for processing medical device data, according to an exemplary embodiment of the present disclosure. In the illustrated example, the input port 702 operates with the device data manager 302 to communicatively couple to the medical device 104. The input port 702 may include one or more serial ports, Ethernet ports, Wi-Fi ports, Bluetooth ports, or USB ports. It should be understood that the DCM 102 may include fewer ports. A configuration file 342 defines the ports to be activated for communication with the medical device 104, including the installation of appropriate drivers.

[0106] Similarly, the DCM 102 includes output ports 704 for connection to the analysis server 122 and the EMR server 108 via the hospital network 108. In the illustrated example, the output ports 704 operate with the interfaces 312 and 322 to communicatively couple to the analysis server 122 and the EMR server 108. The output ports 704 may include one or more serial ports, Ethernet ports, Wi-Fi ports, and / or cellular ports. It should be understood that the DCM 102 may include fewer or more output ports. The configuration file 342 defines the ports to be activated for communication with the medical devices 104, including the installation of appropriate drivers.

[0107] The example processor 706 defines one or more instructions that perform the operations described in connection with Figure 3. The processor 706 includes an input module 710 that includes a device data manager 302 and medical device drivers 712. The example device drivers 712 are installed based on the type of medical device 104 used with the DCM 102. Each driver includes instructions regarding how data from the medical device is formatted or structured, which allows the device data manager 302 to identify different data types for patient de-identification or inclusion within the first and second data streams or subsets 316 / 326.

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

[0109] The processor 706 also includes a data conversion module 718. The example data conversion module 718 is configured to convert medical device data from a first format to a second format, as specified by the configuration file 342. Different data types in the 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, the module 718 may include sections for JSON, XML, HTTP, HTML, etc.

[0110] 7 may be configured as an IoT agent that leverages an IoT framework to provide secure, bidirectional connectivity from the DCM to the analytics server 122. The DCM 102 may use the IoT framework for device management, configuration, security, and the transmission of connectivity health statistics. In some embodiments, the DCM 102 is configured with an IoT device shadow for the analytics server 122 to communicate anonymized first data stream or subset 318 and / or log / health data 319.

[0111] The processor 706 may comprise digital and analog circuits structured as a microprocessor, an application-specific integrated circuit ("ASIC"), a controller, etc. For example, the processor 106 may include a Digi ConnectCore® 6UL module with an NXP i.MX6UL-2 Cortex-A7 528 MHz CPU and a 256 MB / 1 GB NAND and DDR3 flash drive. The DCM 102 also includes an 802.11a / b / g / n / ac Wi-Fi radio and a Bluetooth® 4.2 radio connected to corresponding input ports 702 and / or output ports 704. The processor 106 of the DCM 102 may be configured to operate with the Yocto Linux® operating system and contains drivers for the Digi chipset. The processor 106 may run a connectivity application that allows a user to manage network and configuration settings via a configuration file manager 350. The connectivity application also allows the DCM 102 to receive remotely provided software and firmware updates. III. Example DCM Configuration Procedure

[0112] 8 is a flow diagram of an example procedure 800 for configuring DCM 102 with configuration file 342, according to an example embodiment of the present disclosure. Although procedure 800 is described with reference to the flow diagram illustrated in FIG. 8, it should be understood that many other ways of implementing the steps associated with procedure 800 may be used. For example, the order of many of the blocks may be changed, certain blocks may be combined with other blocks, and many of the described blocks may be optional. In an embodiment, the number of blocks may be changed. Furthermore, the step of transmitting confirmation of receipt of configuration file 342 may be omitted. The actions described in procedure 800 are specified by one or more instructions and may be implemented among multiple devices, including, for example, DCM 102, computer 400, and / or server 500.

[0113] 8 when the DCM 102 receives or otherwise obtains a configuration file 342 (block 802). In some embodiments, the configuration file 342 may be created locally at the DCM 102 via a user interface provided by the configuration file manager 350. Once obtained, the DCM 102 stores the configuration file (block 804). The DCM 102 then reads the configuration file 342 and determines the parameters / attributes that are defined. Based on the defined parameters / attributes, the DCM 102 accesses and installs the corresponding device driver to process data from the defined medical device type (block 806).

[0114] The example DCM 102 also provisions one or more input ports of the input interface for communication with the medical device 104 based on the defined parameters / attributes of the configuration file 342 (block 808). The example DCM 102 further provisions one or more output ports of the output interface for communication with the analysis server 122 based on the defined parameters / attributes of the configuration file 342 (block 810). In addition, the example DCM 102 provisions one or more output ports of the output interface for communication with the EMR server 108 based on the defined parameters / attributes of the configuration file 342 (block 812). Provisioning the input / output ports may include activating the identified input and output ports and installing any associated drivers.

[0115] In addition to the above, DCM 102 provisions the data manager to convert medical device data from the medical device into a format defined by configuration file 342 for transmission to EMR server 108 (block 816). In some instances, DCM 102 provisions the data manager to convert medical device data into a standardized format for processing by analysis server 122. DCM 102 may then complete the configuration process by transmitting a confirmation message 817 indicating the configuration, for example, to computer 400 or server 500 of Figures 4 and 5, respectively (block 818). The example procedure 800 then ends, and DCM 102 is ready to process the medical device data. IV. Exemplary DCM Medical Device Data Processing Procedures

[0116] 9 is a flow diagram of an example procedure 900 for processing medical device data using a DCM 102, according to an example embodiment of the present disclosure. While procedure 900 is described with reference to the flow diagram illustrated in FIG. 9 , it should be understood that many other ways of implementing the steps associated with procedure 900 may be used. For example, the order of many of the blocks may be changed, certain blocks may be combined with other blocks, and many of the described blocks may be optional. In an embodiment, the number of blocks may be changed. Additionally, the step of encrypting the data subset may be omitted. The actions described in procedure 900 are defined by one or more instructions and may be implemented among multiple devices, including, for example, the DCM 102, the medical device 104, the analysis server 122, and / or the EMR server 108.

[0117] The example procedure 900 begins when the DCM 102 receives medical device data 330 from a communicatively coupled medical device 104 (block 902). The DCM 102 records snapshots of the received data based on periodic intervals, creating two separate data streams or subsets (block 904). In some cases, the same medical device data is used for each subset. In other cases, the data subsets may include different medical device data and portions of the same medical device data.

[0118] For the first data stream or subset, the DCM 102 anonymizes the data, creating anonymized data 318 (block 906). This includes removing any data that could be used to identify the patient. In some cases, patient identifiers are replaced with session identifiers and / or random character sets. The DCM 102 then adds log / health data 319 to the anonymized data 318 (block 908). The DCM 102 may then encrypt the anonymized data 318 and / or the log / health data (block 910).

[0119] The DCM 102 then checks whether a connection to the analytics server 122 exists (block 912). In some instances, the DCM 102 may use the Message Queuing Telemetry Transport ("MQTT") messaging protocol to check the connection status. If a connection does not exist, the DCM 102 stores one or more encrypted messages with the de-identified data 318 and / or log / health data 319 in a persistent memory device (block 914). The DCM 102 continues to store subsequent encrypted messages until a data connection is detected. Once a data connection is detected, the DCM 102 transmits the encrypted messages with the de-identified data 318 and / or log / health data 319 to the analytics server 122 via one or more networks 106, 120 (block 916). The example procedure 900 then returns to block 902 to process the newly received medical device data.

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

[0121] The DCM 102 then checks whether a connection to the EMR server 108 exists (block 926). In some instances, the DCM 102 may use the MQTT messaging protocol or the Minimal Lower Layer Protocol ("MLLP") to check the connection status. If a connection does not exist, the DCM 102 stores one or more encrypted messages with the transformed data 328 and / or log / health data 319 in a persistent memory device (block 928). The DCM 102 continues to store subsequent encrypted messages until a data connection is detected. Once a data connection is detected, the DCM 102 transmits the encrypted messages with the transformed data 328 and / or log / health data 319 to the EMR server 108 via the medical network 106 and / or serial connection (block 930). The example procedure 900 then returns to block 902 to process the newly received medical device data. V. conclusion

[0122] It should be understood that various changes and modifications to the present 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

[Claim 1] The invention described in this specification.

Images