Patent Description:
Some manufacturers attempt to obtain medical device data by having a sales representative or technician physically visit each medical device to remove at least some of the device data, including diagnostic information. However, this is an extremely labor intensive process. Additionally, this manual process oftentimes neglects or overlooks many medical devices from data collection due to the time and costs involved in the data collection. This can create gaps when the data is later analyzed. Further, this manual collection method is not timely since the data may only be analyzed days to weeks, or even months after collection.

Some other medical device manufacturers are granted limited access to medical device data that is stored within a medical network. In these instances, the device manufacturers have access to a data repository that is separate from patient records and hospital systems. One issue is that the data is limited to medical data that is transmitted from the medical device, and may not include data of interest to a manufacturer, such as diagnostic or usage information. Further, the data is formatted in a manner designated by the hospital system, which may make large-scale handling, processing, and analysis of the data difficult or impossible. Moreover, a device manufacturer with medical devices in tens to hundreds of different hospital systems (each with their own protocols and data storage requirements) would have to access each system separately and perform any data conversion to produce a uniform and useable data set.

The above-described issues deprive medical device manufacturers of valuable medical device data. For instance, device manufacturers could use the device data to address device issues, identify device operational trends, identify treatment trends, identify device operational recommendations, or help plan development of the next generation of devices. The lack of data oftentimes makes medical device manufactures reactive to issues rather than being proactive, which over the long term can impact the quality of patient treatment.

<CIT> discloses a wireless device for medical data transmission that comprises a wireless interface, a processor, and a medical equipment interface arranged to provide connection to an item of medical equipment. The processor is arranged to communicate with the medical equipment interface and the wireless interface, and is also arranged to perform a protocol adaptation. The protocol adaptation takes place from a protocol of incoming data received at the medical equipment interface to a protocol of data to be transmitted through the wireless interface, or vice versa. The protocol adaptation comprises individual or combined filtering, gathering, partitioning, prioritizing, or discarding the incoming data. The processor is further arranged to read a configuration file containing an adaptation specification that pertains to the protocol adaptation; and to perform the protocol adaptation in compliance with the adaptation specification.

<CIT> discloses a system comprising a processor, a medical device transceiver, a user interface, a data relay transceiver, a memory coupled to the processor, and storing instructions. The processor executes the instructions in the memory to receive data from a medical device using the medical device transceiver and transmits the data to an intermediary device using the data relay transceiver.

<CIT> discloses a device for connecting a medical apparatus to a network. The device collects data from the medical apparatus and performs a variety of processing functions, such as trending, protocol translation, generating reports, etc. related to the collected data. The device then transmits the collected data over a network to interested parties.

A digital communication module ("DCM") for the transmission of data from a medical device is disclosed herein. The example DCM is positioned between a processor (or therapy module) of a medical device and a medical network. In some embodiments, the DCM is external to the medical device (connected via a serial connection or Ethernet connection). In other embodiments, the DCM is included within or integrated with a 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 a medical network and an external server (e.g., a medical device manufacturer server using an IoT shadow service) that is separate from the medical network.

In embodiments, the DCM receives medical device data from a processor or therapy module of a medical device. The DCM is configured to transmit two separate streams of the medical device data to the medical network. For a 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 a device manufacturer of the corresponding medical device. For a second data stream, the DCM provides the medical device data in a second format for transmission to EMR servers or hospital systems within the hospital network. In some instances, the DCM may de-identify the medical device data for the first data stream and add log/health data, which is of interest to the device manufacturer and permits advanced analytics to evaluate the operation of the medical devices. For the second data stream, the DCM transmits the medical device data with patient identifying information for inclusion into an appropriate EMR or for use by an appropriate hospital system. The DCM accordingly provides medical device manufacturers easy access to valuable medical device data in a common format for data analytics while also providing a hospital system the medical device data in the same format as used internally previously (thereby requiring no change to a medical network).

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

The example DCM is operational with any type of medical device. For example, the DCM may operate with medical devices for plasmapherisis, 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 or generally individually as medical fluid delivery or treatment.

The above modalities may be provided by a medical fluid delivery machine that houses components needed to deliver medical fluid, such as one or more pumps, valves, heaters if needed, online medical fluid generation equipment if needed, sensors, such as pressure sensors, conductivity sensors, temperature sensors, air detectors, blood leak detectors, and the like, user interfaces, and control units, which may employ one or more processors and memory to control the above-described equipment. The medical fluid delivery machine may also include one or more filters, such as a dialyzer or hemofilter for cleansing blood and/or an ultrafilter for purifying water, dialysis fluid, or other fluid.

The DCM and the medical fluid delivery machine described herein may be used with home-based machines. For example, the systems may be used with home HD, HF or HDF machines, which are operated at the patient's convenience. One such home system is described in <CIT>, entitled "High Convection Home Hemodialysis/Hemofiltration And Sorbent System", filed November <NUM>, <NUM>, assigned to the assignees of the present application. Other such home systems are described in <CIT>, entitled "Enclosure for a Portable Hemodialysis System", filed August <NUM>, <NUM>.

As described in detail below, the DCM of the present disclosure may operate within an encompassing platform system that may include many machines comprising many different types of devices, patients, clinicians, doctors, service personnel, electronic medical records ("EMR") databases, a website, a resource planning system handling data generated via the patient and clinician communications, and business intelligence. The DCM of the present disclosure operates seamlessly within the overall system and without contravening its rules and protocols.

According to the present invention, there is provided a digital communication apparatus according to claim <NUM>.

In a first embodiment of the digital communication apparatus of the present invention, the processor is configured to receive the medical data in the first format from the medical device via the 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 specified by the configuration file, convert a second subset of the medical data to the 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 specified by the configuration file.

In a second embodiment of the digital communication apparatus of the present invention, which may be combined with the first embodiment, the first subset of the medical data is the same as the second subset of the medical data.

In a third embodiment of the digital communication apparatus of the present invention, which may be combined with the first and/or second embodiment, the output interface provides for communicative coupling to at least one of an electronic medical record ("EMR") server, a middleware server, or an integration engine via the medical network, and the processor is configured to transmit the second subset of the medical data in the second data format to the at least one of the EMR server, the middleware server, or the integration engine using the same or the different output port as specified by the configuration file.

In a fourth embodiment of the digital communication apparatus of the present invention, which may be combined with any of the first to third embodiments, the at least one of the Ethernet port and the wireless port provide for communicative coupling to a remote server that is external to the medical network, and the processor is configured to transmit the first subset of the medical data in the first data format to the remote server using the at least one of the Ethernet port or the wireless port.

In a fifth embodiment of the digital communication apparatus of the present invention, which may be combined with any of the first to fourth embodiments, 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.

In a sixth embodiment of the digital communication apparatus of the present invention, which may be combined with the fifth embodiment, the messaging protocol includes a Message Queuing Telemetry Transport ("MQTT") publish-subscribe network protocol.

In a seventh embodiment of the digital communication apparatus of the present invention, which may be combined with any of the first to sixth embodiments, the configuration file specifies a first destination network address that is to receive the first subset of the medical data in the first data format, and specifies a second destination network address that is to receive the second subset of the medical data in the second data format, and the first destination network address is associated with a network domain that is external to the medical network and the second destination network address is associated with a network domain that includes the medical network.

In an eighth embodiment of the digital communication apparatus of the present invention, which may be combined with any of the first to seventh embodiments, the processor is configured to generate log data and health data include the log data and the health data with the first subset of the medical data for transmission in the first data format via the output interface via one of the output ports as specified by the configuration file, convert the log data to the second data format, and include the log data with the second subset of the medical data for transmission via the same or the different output port as specified by the configuration file.

In a ninth embodiment of the digital communication apparatus of the present invention, which may be combined with the eighth embodiment, the log data includes at least one of an identification of a medical device type, an identification of a medical device serial number, a time stamp from which the received medical data was generated by the medical device or received by the processor from the medical device, an identifier of the apparatus, a timestamp for the first subset of the medical data, or a monotonic time stamp, and the health information 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 for processing the first and second subsets of the medical data for transmission.

In a tenth embodiment of the digital communication apparatus of the present invention, which may be combined with any of the first to ninth embodiments, the processor is configured to at least one of anonymize patient information included within the first subset of the medical data before transmission, or encrypt the first subset of the medical data before transmission.

In an eleventh embodiment of the digital communication apparatus of the present invention, which may be combined with any of the first to tenth embodiments, the processor is configured to receive a stream of the medical data, create a snapshot of the medical data at periodic intervals, and provide 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.

In a twelfth embodiment of the digital communication apparatus of the present invention, which may be combined with the eleventh embodiment, the periodic intervals have a period between five seconds and sixty seconds.

In a thirteenth embodiment of the digital communication apparatus of the present invention, which may be combined with the eleventh and/or twelfth embodiment, the processor is configured to use event tracking to identify changes to the medical data between snapshots, and include only the changed medical data from a previous snapshot as at least one of the first subset of the medical data or the second subset of the medical data.

In a fourteenth embodiment of the digital communication apparatus of the present invention, which may also be combined with any of the first to thirteenth embodiments, the configuration file specifies a type of the medical device and that the medical data to be received from the medical device is provided in the first data format.

In a fifteenth embodiment of the digital communication apparatus of the present invention, which may also be combined with any of the first to fourteenth embodiments, 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 nutrition compounding machine.

In a sixteenth embodiment of the digital communication apparatus of the present invention, which may also be combined with any of the first to fifteenth embodiments, the first data format includes JavaScript Object Notation ("JSON"), Hypertext Transfer Protocol ("HTTP"), or a binary protocol.

In a seventeenth embodiment of the digital communication apparatus of the present invention, which may also be combined with any of the first to sixteenth embodiments, the second data format includes a Health-Level <NUM> ("HL7") protocol, a Fast Healthcare Interoperability Resources ("FHIR") protocol, or a binary protocol.

In an eighteenth embodiment of the digital communication apparatus of the present invention, which may also be combined with any of the first to seventeenth embodiments, 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.

In a nineteenth embodiment of the digital communication apparatus of the present invention, which may also be combined with any of the first to eighteenth embodiments, the medical data includes at least one of event information comprising transitions between fill, dwell, and drain phase of a dialysis cycle, alarm information, treatment programming information, or treatment information comprising an estimated fill rate, a drain rate, and an amount of ultrafiltration removed.

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 conveying medical device data to medical device manufacturers.

It is another advantage of the present disclosure to use a configuration file to configure certain drivers and/or hardware interfaces on the DCM.

A digital communication module ("DCM") for transmission of data from a medical device is disclosed. The example 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 server of a medical device manufacturer). In some embodiments, the DCM de-identifies the medical device data that is 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. Further, in some embodiments, the DCM may convert the medical device data to a different format for the hospital system. The example DCM is provisioned via a configuration file that specifies input interface parameters, output interface parameters, device driver parameters, and/or data conversion parameters. After receipt of a configuration file, the DCM is configured to provision the specified input/output interfaces in addition to install specified device drivers and provision data conversion/encryption mechanisms.

The DCM is configured to operate with many different types of medical devices and communicate via different types of interfaces, such as a serial connection (e.g., an RS-<NUM> or RS-<NUM> connection), an Ethernet connection, a Wi-Fi connection, a Bluetooth® connection, and/or a universal serial bus ("USB") connection. The configurability of the DCM enables its use with many different types of medical devices, such as a peritoneal dialysis machine, a critical care dialysis machine, a continuous renal replacement therapy ("CRRT") machine, a hemodialysis machine, a water preparation/purification device, a nutrition compounding machine, an infusion pump, etc. Further, the configurability of the DCM enables its use within differently configured hospital systems. The configurability of the DCM accordingly enables medical device data to be transmitted to an external server without having to make connectivity or networking changes to medical devices or hospital systems.

Reference is made herein to medical device data. As disclosed, medical device data (e.g., medical data) is generated at a medical device and transmitted to the DCM. The medical device data includes treatment programming information, which comprises one or more parameters that define how a medical device is to operate to administer a treatment to a patient. For a peritoneal dialysis therapy, the parameters may specify an amount (or rate) of fresh dialysis fluid to be pumped into a peritoneal cavity of a patient, an amount of time the fluid is to remain in the patient's peritoneal cavity (i.e., a dwell time), and an amount (or rate) of used dialysis fluid and ultrafiltration ("UF") that is to be pumped or drained from the patient after the dwell period expires. For a treatment with multiple cycles, the parameters may specify the fill, dwell, and drain amounts for each cycle and the total number of cycles to be performed during the course of a treatment (where one treatment is provided per day or separate treatments are provided during the daytime and during nighttime). In addition, the parameters may specify dates/times/days (e.g., a schedule) in which treatments are to be administered by the medical fluid delivery machine. Further, parameters of a prescribed therapy may specify a total volume of dialysis fluid to be administered for each treatment in addition to a concentration level of the dialysis fluid, such as a dextrose level. For an infusion therapy, the parameters may include a volume to be infused, a medication to be infused, a medication concentration, a medication dosage, and/or an infusion rate.

The medical device data also includes event information that relates to administration of the treatment. The event information may include data generated by a medical device that is indicative of measured, detected, or determined parameter values. For example, while a prescribed therapy may specify that a treatment is to comprise five separate cycles, each with a <NUM> minute dwell time, a medical fluid delivery device may administer a treatment where fewer cycles are provided, each with a <NUM> minute dwell time. The medical device monitors how the treatment is administered and accordingly provides parameters that are indicative of the operation. The parameters for the treatment data may include, for example, a total amount of dialysis fluid administered to the patient, a number of cycles operated, a fill amount per cycle, a dwell time per cycle, a drain time/amount per cycle, an estimated amount of UF removed, a treatment start time/date, and/or a treatment end time/date. The treatment data may also include calculated parameters, such as a fill rate and a drain rate, 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 a treatment, a duration of the alarm, a time of the alarm, an event associated with the alarm, and/or an indication as to whether the issue that caused the alarm was resolved or whether the alarm was silenced.

The medical device data further includes device machine logs that include diagnostic information, fault information, etc. The diagnostic information may include information indicative of internal operations of a medical device, such as faults related to pump operation, signal errors, communication errors, software issues, etc. The medical device data may be transmitted as a data stream or provided at periodic intervals. In some instances, the medical device data may be transmitted as events or other changes to the data occur.

Reference is also made herein to log data and health data that is generated by the example DCM. The log data includes an identification of a therapy (medical) device type, identification of a therapy device serial number, a timestamp from which the treatment data was generated or received from the therapy device, an identifier of the DCM, a timestamp for the snapshot, and/or a DCM monotonic timestamp. The health information includes, for example, DCM system memory information, DCM central processing unit ("CPU") usage information, network connectivity information, process/thread information, and information regarding embedded software applications.

While the following shows a DCM that partitions medical device data into two separate data streams or subsets, it should be appreciated 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, include a different data format, and/or include different subsets of medical device data and/or log/health data. In addition to an analytics server of a manufacturer, the medical device data may be provided to a data analytics server of a pharmaceutical/dialysis fluid manufacturer, a continuous quality improvement system, an auditor, a regulator, etc..

<FIG> is a diagram of a DCM environment <NUM>, according to an example embodiment of the present disclosure. The example DCM environment <NUM> includes at least one DCM <NUM> communicatively coupled to a medical device <NUM>. The DCM <NUM> may be connected to the medical device <NUM> via a serial connection, an Ethernet connection, a USB connection, a Wi-Fi connection, a Bluetooth® connection, etc. The example DCM <NUM> may include a network gateway, such as an IoT gateway.

In the example embodiment, the DCM <NUM> is configured to only receive medical device data from the medical device <NUM>. This uni-directional communication configuration prevents another device from being able to access, program, or otherwise communicate with the medical device <NUM> via the DCM <NUM>. However, in some embodiments, the DCM <NUM> may have a bi-directional communication link with the medical device <NUM> to enable data, programming instructions, or information to be transmitted to the medical device. While only one DCM <NUM> and medical device <NUM> are shown in <FIG>, it should be appreciated that the environment <NUM> may include tens to hundreds or thousands of medical devices and respective DCMs.

The example medical device <NUM> is configured to accept one or more parameters specifying a treatment or prescription (i.e., treatment programming information). During operation, the medical device <NUM> writes event, diagnostic, and/or operational data to one or more log files. In some embodiments, the medical device <NUM> may store medical device data to a log file periodically, such as every five seconds to sixty seconds and/or after there is a change in data. The new medical device data written to the log file is transmitted to the DCM <NUM>. In some embodiments, the medical device <NUM> creates the medical device data in a JavaScript Object Notation ("JSON") format, a HyperText Markup Language ("HTML") format, an Extensible Markup Language ("XML") format, a comma-separated values ("CSV") format, a text format, and/or a Health-Level-<NUM> ("HL7") format.

The example medical device <NUM> may include one or more control interfaces <NUM> for displaying instructions and receiving control inputs from a user. The control interface <NUM> may include buttons, a control panel, or a touchscreen. The control interface <NUM> may also be configured to enable a user to navigate to a certain window or user interface on a screen of the medical device <NUM>. The control interface <NUM> may also provide instructions for operating or controlling the medical device <NUM>.

The example medical device <NUM> also includes a processor or therapy module <NUM>. The processor or therapy module <NUM> of the medical device <NUM> operates according to one or more instructions for performing a treatment on a patient. The instructions may be acquired via the control interface <NUM>. The processor or therapy module <NUM> also monitors device components for issues, which are documented as diagnostic information. The processor or therapy module <NUM> creates medical device data in conjunction with operating one or more pumps or other components to administer the treatment. The processor or therapy module <NUM> transmits the medical device data to the DCM <NUM>.

The example DCM environment <NUM> also includes a medical network <NUM>, which communicatively couples the DCM <NUM> to an EMR server <NUM> and one or more hospital systems <NUM>. The medical network <NUM> can include any number of gateways, routers, system hubs, switches, and/or network appliances for establishing communication connections and routing data. The medical network <NUM> may include one or more firewalls that restrict access to only authorized remote devices and/or servers. The medical network <NUM> may include any local area network ("LAN"), Ethernet network, Wi-Fi network, or combinations thereof.

As shown in <FIG>, the DCM <NUM> may be wired or wirelessly coupled to the medical network <NUM>. In some embodiments, the connection may include an Ethernet connection, a Wi-Fi connection, and/or a cellular connection. Additionally or alternatively, the DCM <NUM> may have a serial connection to the EMR server <NUM> (or the hospital system <NUM>) that bypasses the medical network <NUM>.

<FIG> is another diagram of the DCM environment <NUM>, according to an example embodiment of the present disclosure. In this embodiment, the DCM <NUM> is included within and/or integrated with the medical device <NUM>. The DCM <NUM> may include, for example, a Digi ConnectCore® 6UL module, which has a NXP i. MX6UL-<NUM>, Cortex-A7 <NUM> CPU and <NUM> MB/<NUM> GB NAND and DDR3 flash drives. The DCM <NUM> may be connected to a communication bus of the medical device <NUM> for receiving medical device data. The DCM <NUM> (including the DCM of <FIG>) also includes an <NUM>. 11a/b/g/n/ac Wi-Fi radio and/or a Bluetooth® <NUM> radio. The DCM <NUM> may include a Yocto Linux operating system and contains drivers for the Digi chipset.

The example EMR server <NUM> of <FIG> and <FIG> is configured to manage patient EMRs that are stored in a database of a memory device <NUM>. The EMR server <NUM> is configured to receive medical device data, parse the data based on patient identifier, locate corresponding patient EMRs in the memory device <NUM>, and store the parsed medical device data to the identified EMR. The EMR server <NUM> may also access one or more EMRs in response to request messages that identify the respective patients. The EMR server <NUM> may store the medical device data in a HL7 format, a binary version <NUM> format, a binary version <NUM> format, or a Fast Healthcare Interoperability Resources ("FHIR") format.

The example DCM environment <NUM> 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 <NUM> may also include a middleware system and/or an integration engine. The DCM environment <NUM> enables user devices (e.g., smartphones, laptop computers, workstations, tablet computers, etc.) to read and/or write to the medical device data stored in the EMRs of the memory device <NUM>.

The example DCM environment <NUM> of <FIG> also includes an external network <NUM> that is communicatively coupled to an analytics server <NUM>. The external network <NUM> 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 <NUM>, <NUM>, or <NUM> cellular network), or combinations thereof. The external network <NUM> is communicatively coupled to the medical network <NUM> via one or more Ethernet and/or cellular connections. The medical network <NUM> may be assigned a domain address or sub-domain address, which is recognized by the external network <NUM> for routing data to and/or from devices connected to the medical network <NUM>. In some embodiments, a cellular connection of the DCM <NUM> may bypass the medical network <NUM> and instead couple to a cellular network of the external network <NUM>.

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

The analytics server <NUM> is configured to periodically analyze the received medical device data for certain key performance indicators ("KPIs") related to operation of the medical device <NUM>. The KPIs may be related to treatment trends, component (e.g., pump or filter) usage, alert/alarm trends, etc. The analytics server <NUM> may analyze the medical device data to determine recommendations and/or guidelines to improve operation of the medical device <NUM> and/or improve treatment protocols for certain disease conditions. For example, the analytics server <NUM> may determine more optimal peritoneal dialysis programming parameters for patients that have a certain degree of kidney failure. The analysis of the medical device data may include the analytics server <NUM> providing standardization, parsing of DCM device logs, and analysis of DCM health statistics.

In the illustrated example, the medical device <NUM> is the PrisMax CRRT machine manufactured by Baxter International Inc. It should be appreciated that in other embodiments, the medical device <NUM> may include any other renal failure therapy machine, infusion pump, physiological sensor, etc. The medical device <NUM> may include, for example, an infusion pump (e.g., a syringe pump, a linear peristaltic pump, a large volume pump ("LVP"), an ambulatory pump, multi-channel pump), a nutritional compounding 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.

Regarding renal failure therapy machines, due to various causes, a patient's renal system can fail. For instance, a patient experiencing renal failure can no longer balance water and minerals or excrete daily metabolic load. Toxic end products of nitrogen metabolism (urea, creatinine, uric acid, and others) can accumulate in the patient's blood and tissue. Kidney failure and reduced kidney function have been treated with dialysis. Dialysis treatment for replacement of kidney functions is critical to many people because the treatment is life saving.

HF is accomplished by adding substitution or replacement fluid to the extracorporeal circuit during treatment (typically ten to ninety liters of such fluid). The substitution fluid and the fluid accumulated by the patient in between treatments is ultrafiltered over the course of the HF treatment, providing a convective transport mechanism that is particularly beneficial in removing middle and large molecules (in hemodialysis there is a small amount of waste removed along with the fluid gained between dialysis sessions, however, the solute drag from the removal of that ultrafiltrate is not enough to provide convective clearance).

Another type of kidney failure therapy is peritoneal dialysis, which infuses a dialysis solution, also called dialysis fluid, into a patient's peritoneal cavity via a catheter. The dialysis fluid contacts the peritoneal membrane of the peritoneal cavity. Waste, toxins and excess water pass from the patient's bloodstream, through the peritoneal membrane and into the dialysis fluid due to diffusion and osmosis, i.e., an osmotic gradient occurs across the membrane. An osmotic agent in dialysis provides the osmotic gradient. The used or spent dialysis fluid is drained from the patient, removing waste, toxins and excess water from the patient. This cycle is repeated, e.g., multiple times.

There are various types of peritoneal dialysis therapies, 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 used 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 through the catheter and into the patient. The patient disconnects the catheter from the fresh dialysis fluid bag and allows the dialysis fluid to dwell within the peritoneal cavity, wherein the transfer of waste, toxins and excess water takes place. After a dwell period, the patient repeats the manual dialysis procedure, for example, four times per day, each treatment lasting about an hour. Manual peritoneal dialysis requires a significant amount of time and effort from the patient, leaving ample room for improvement.

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

APD machines pump used or spent dialysate from the peritoneal cavity, though the catheter, and to the drain. As with the manual process, several drain, fill and dwell cycles occur during dialysis. A "last fill" occurs at the end of APD and remains in the peritoneal cavity of the patient until the next treatment.

<FIG> is a diagram of the example DCM <NUM> of <FIG> and <FIG>, according to an example embodiment of the present disclosure. The example DCM <NUM> includes a data device manager <NUM> that is configured to generate two parallel data steams for medical device data received from a medical device <NUM>. The DCM <NUM> also includes a log manager <NUM> and a system health monitor <NUM> to acquire or provide information related to the DCM. For a first data stream or subset provided to the analytics server <NUM>, the DCM <NUM> includes an external agent <NUM>, an external interface <NUM>, and an external persistent storage device <NUM>. For a second data stream or subset provided to the EMR server <NUM>, the DCM <NUM> includes an internal agent <NUM>, an internal interface <NUM>, and an internal persistent storage device <NUM>.

The example components <NUM> to <NUM>, <NUM>, and <NUM> of the DCM may be implemented using one or more computer programs or applications. The programs or the applications may be defined by a series of computer instructions that are 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 media. The instructions may be configured to be executed by a processor of the DCM <NUM>, which when executing the series of computer instructions performs or facilitates the performance of all or part of the disclosed methods and procedures disclosed herein. The persistent storage devices <NUM> and <NUM> may include any memory device including RAM, ROM, flash memory, etc..

The example data device manager <NUM> is configured to interface with the medical device <NUM> for receiving the medical device data. The data device manager <NUM> is configured to create a snapshot of the medical device data at discrete points of time. The time periods may be specified by a configuration file (such as configuration file <NUM>) and include, for example, five second intervals, ten second intervals, thirty second intervals, sixty second intervals, etc. For each snapshot the data device manager <NUM> reads the most recent received data from the medical device <NUM>. In this manner, the device data manager <NUM> provides periodic updates regarding a status of the medical device <NUM>.

In an example, the medical device <NUM> may transmit medical device data <NUM> in a continuous stream, periodic intervals, or after changes to the data. The medical device <NUM> may transmit the medical device data <NUM> in a log file or a stream of messages. The device data manager <NUM> compiles the received data since the last snapshot interval. When the next interval approaches, the device data manager <NUM> compiles the most recent data of the compilation into the snapshot to provide a representation of the medical device <NUM> at that point in time. If multiple events occur during a compilation period, the device data manager <NUM> may include only the most recent event or all of the events that occurred during the time period.

In some instances, the device data manager <NUM> may compare a current snapshot to a previous snapshot. Based on the comparison, the device data manager <NUM> may only include 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 such that only new and/or updated medical device data <NUM> is communicated. For example, a CRRT medical device <NUM> may continuous transmit an estimated UF removed value, which typically does not change during fill and dwell cycles of a PD treatment. As such, the device data manager <NUM> only includes the UF removed value when there are changes to the value. In another example, an alarm may activate at a certain time. A device status may be included in the medical device data <NUM> that is indicative that the alarm is still active. However, the device data manager <NUM> only includes a notice in a first snapshot of a time the alarm activate (and a an alarm type) and a time the alarm was silenced or reset in a second subsequent snapshot, without including indications that the alarm was active in the intermediate snapshots.

In other embodiments, the medical device <NUM> may selectively only transmit medical device data that has changed from previous values or reflect a new event. In these instances, the device data manager <NUM> writes the received medical device data <NUM> to the appropriate snapshot.

In conjunction with creating a snapshot of the medical device data <NUM>, the example device data manager <NUM> creates two separate data sets or streams. A first data set or stream <NUM> is for the analytics server <NUM>. A second data subset or stream <NUM> is for the EMR server <NUM> and/or the hospital system <NUM>. The first data stream or subset <NUM> may include the same medical device data <NUM> from the snapshot as the second data stream or subset <NUM>. In other embodiments, the may include additional or fewer medical device data <NUM> from the snapshot compared to the second data stream or subset <NUM>. For instance, the device data manager <NUM> may be configured to include diagnostic data (identified by metadata, data field label, placement, etc.) in the first data stream or subset <NUM> while not including the diagnostic data in the second data stream or subset <NUM>. Further, the device manager <NUM> may include patient-identifying data in the second data stream or subset <NUM> while not including any patient-identifying data in the first data stream or subset <NUM>.

The example DCM <NUM> includes the external agent <NUM> for de-identifying the first data stream or subset <NUM> to generate a de-identified first data stream or subset <NUM>. The external agent <NUM> may be configured to search for data labels or keywords that are indicative of patient names, hospital-assigned identifiers, social security number, etc. In some instances, the patient-specific information may be replaced with a (randomly) generated session identifier that is used by the analytics server <NUM> to associate medical device data from the same treatment. In other embodiments, the patient-identifying information is removed or deleted by the external agent <NUM>.

The example external agent <NUM> is also configured to combine or include log and/or health data <NUM> with the de-identified first data stream or subset <NUM>. The log data is generated by the log manager <NUM> and includes an identification of a medical device type, identification of a medical device serial number, a timestamp from which the medical device data <NUM> was generated or received from the medical device <NUM>, an identifier of the DCM <NUM>, a timestamp for the snapshot created by the device data manager <NUM>, and a DCM monotonic timestamp. The identification of a medical device type, identification of a medical device serial number, and identifier of the DCM <NUM> may be specified in the configuration file <NUM>. In some instances, the identification of a medical device type and the identification of a medical device serial number may be reported by the medical device <NUM>. The log manager <NUM> is configured to store this information create the appropriate timestamps as the medical device data <NUM> is received and/or the snapshots are created. The log manager <NUM> then transmits the log data to the external agent <NUM> for each snapshot corresponding to the de-identified first data stream or subset <NUM> that is transmitted to the analytics server <NUM>.

The example system health manager <NUM> is configured to acquire and/or determine health information relayed to the DCM <NUM>. The system health manager <NUM> is configured to transmit to the external agent <NUM> DCM system memory information (related to the persistent storage devices <NUM> and <NUM>), DCM CPU usage information, network connectivity information, process/thread information, and/or information related to one or more software applications operating on the DCM <NUM>. To acquire this information, the system health manager <NUM> is configured to access and/or read memory usage information of the persistent storage devices <NUM> and <NUM>. Further, the system health manager <NUM> is configured to monitor one or more processors of the DCM <NUM> that implement the operations described herein. The system health monitor <NUM> also monitors network connections and/or detects loss of network connections via lack of reception of acknowledgement messages with the analytics server <NUM> and/or the EMR server <NUM>. Similar to the log manager <NUM>, the system health manager <NUM> transmits the health information to the external agent <NUM> for transmission with the de-identified first data stream or subset <NUM>. In some instances, the configuration file <NUM> may specify which information is to be acquired by the system health monitor <NUM> and/or specify which of the health information is to be provided to the external agent <NUM> and/or the internal agent <NUM>.

The example external agent <NUM> configures the de-identified first data stream or subset <NUM> and/or the log/health data <NUM> for transmission to the analytics server <NUM>. The external agent <NUM> receives a destination IP address of the analytics server <NUM> from the configuration file <NUM>. The external agent <NUM> may also receive domain connectivity information for the medical network <NUM> and/or API connection information for the analytics server <NUM> from the configuration file <NUM>. The external agent <NUM> creates one or more messages with the de-identified first data stream or subset <NUM> and/or the log/health data <NUM> for transmission to the analytics server <NUM> using the destination address and networking domain information provided by configuration file <NUM>.

In some embodiments, the external agent <NUM> encrypts the one or more messages including the de-identified first data stream or subset <NUM> and/or the log/health data <NUM>. The external agent <NUM> may use an encryption protocol and/or private key that is specified by or provided by the configuration file <NUM>. For example, the configuration file <NUM> may specify that the external agent <NUM> is configured to use transport layer security ("TLS") and/or using AES <NUM> GCM cypher for encryption. The external agent transmits the (encrypted) messages to the external interface <NUM>.

In some embodiments, the external interface <NUM> (and/or the internal interface <NUM>) is configured to use MQ Telemetry Transport ("MQTT") for transmitting messages with the de-identified first data stream or subset <NUM> and/or the log/health data <NUM> to the analytics server <NUM>. In this instance, the external interface <NUM> is configured as a publisher and the analytics server <NUM> is configured as a broker. In other examples, the internal interface <NUM> (and/or the internal interface <NUM>) may be configured to communicate using Minimum Lower Layer Protocol ("MLLP").

In some instances, the example external interface <NUM> is configured to determine if an active connection to the analytics server <NUM> exists. The external interface <NUM> may transmit periodic pings to the analytics server <NUM> to determine a network status based on a response to the pings. In other examples, the external interface <NUM> may determine if an acknowledgement message is received in response to the transmission of a snapshot of de-identified first data stream or subset <NUM> and/or the log/health data <NUM>. If an acknowledgement message is not received within a specified threshold, the external interface <NUM> determines a loss of a network connection has occurred with the analytics server <NUM>. After determining that a connection to the analytics server <NUM> does not exist, the external interface <NUM> is configured to store the encrypted messages containing the de-identified first data stream or subset <NUM> and/or the log/health data <NUM> to the external persistent memory device <NUM>. The external interface <NUM> stores subsequent snapshots of messages containing the de-identified first data stream or subset <NUM> and/or the log/health data <NUM> to the memory device <NUM> until a network connection is reestablished. At that point, the external interface <NUM> transmits all of the stored messages in the memory device <NUM> to the analytics server <NUM>.

In some instances, a connection with the analytics server <NUM> is not established. In these examples, the external interface <NUM> is configured to store the de-identified first data stream or subset <NUM> and/or the log/health data <NUM> to the memory device <NUM> until the data can be retrieved manually by an operator connecting a computer or USB memory device to the DCM <NUM>. The external interface <NUM> may be configured, by the configuration file <NUM>, to store a specified number of hours or days of data. After the specified number of hours or days has elapsed, the external interface <NUM> may overwrite the oldest data with newly received data.

If a connection to the analytics server <NUM> is present, the external interface <NUM> transmits one or more messages with the de-identified first data stream or subset <NUM> and/or the log/health data <NUM> to the analytics server <NUM> (e.g., a specified API at a designated IP address). In some embodiments, the external interface <NUM> may perform an automatic authentication with the analytics server <NUM> before the de-identified first data stream or subset <NUM> and/or the log/health data <NUM> may be transmitted. In an example, the configuration file <NUM> may include authentication information including, for example, an identifier of the DCM <NUM> and/or a unique password for the DCM <NUM>. The external interface <NUM> first transmits the authentication information to the analytics interface <NUM>. After receiving an acceptance message from the analytics server <NUM>, the external interface transmits the transmits one or more messages with the de-identified first data stream or subset <NUM> and/or the log/health data <NUM> to the analytics server <NUM>. In some instances, the external interface <NUM> uses the authentication information to establish a session with the analytics server <NUM>. During this session, the external interface <NUM> may transmit subsequent snapshots of the de-identified first data stream or subset <NUM> and/or the log/health data <NUM> to the analytics server <NUM> without having to re-authenticate. The session may timeout if data is not received within a specified time period, such as five minutes.

In addition to transmitting the de-identified first data stream or subset <NUM> and/or the log/health data <NUM> to the analytics server <NUM>, the DCM <NUM> also transmits the second data stream or subset <NUM> to the EMR server <NUM>. As shown in <FIG>, the device data manager <NUM> transmits the second data stream or subset <NUM> to the internal agent <NUM>. Each transmission may comprise a snapshot of the second data stream or subset <NUM>.

In some embodiments, the internal agent <NUM> is communicatively coupled to the log manager <NUM> and/or the system health manager <NUM>. In these embodiments, the internal agent receives at least some of the log/health data <NUM> that is provided to the external agent <NUM>. For instance, the internal agent may receive, from the log manager <NUM>, information indicative of the medical device type, a serial number of the medical device, and/or a timestamp from which the medical device data was generated or received from the medical device <NUM>. The internal agent combines the log data <NUM>, for example, with the second data stream or subset <NUM>. In other embodiments, the internal agent <NUM> does not receive any log/health data <NUM>.

After combining any log/health data <NUM> with the second data stream or subset <NUM>, the internal agent <NUM> is configured to format the data into a data format that is compatible with or needed by the EMR server <NUM>. In other words, the internal agent creates a conversion of second data stream or subset <NUM> and/or the log data <NUM>. The conversion type may be specified by the configuration file <NUM>. The conversion may be, from, for example, JSON to HL7, binary, and/or FHIR. The internal agent <NUM> may include one or more files and/or algorithms that specifies how, for example, second data stream or subset <NUM> and/or the log data <NUM> in a JSON format is to be converted into HL7, binary, and/or FHIR. The file and/or algorithm may identify JSON data by position, data label, field name, and/or metadata and specify how the data is to be converted, including conversion of data label names, metadata names, numeric format, positioning, etc. The internal agent <NUM> then transmits the converted second data stream or subset <NUM> and/or the log data <NUM> to the internal interface <NUM>.

The example internal interface <NUM> is configured to check for a connection to the EMR server <NUM> in a similar manner as the external interface <NUM> checks for a connection with the analytics server <NUM>. Additionally for serial connections, the internal interface <NUM> may check for the presence of a serial connector into a port of the DCM <NUM>. If a connection is not present, the internal interface <NUM> stores the converted second data stream or subset <NUM> and/or the log data <NUM> to the internal persistent memory device <NUM>. If a connection is present, the internal interface <NUM> transmits one or more messages with the second data stream or subset <NUM> and/or the log data <NUM> to the EMR server <NUM> (including any previously stored messages in the memory device <NUM> with previous snapshots of the second data stream or subset <NUM> and/or the log data <NUM>). In some embodiments, the internal interfere <NUM> may encrypt the messages (for non-serial connections) with the converted second data stream or subset <NUM> and/or the log data <NUM> if the EMR server <NUM> supports conversion.

The example DCM <NUM> of <FIG> also includes a configuration file manager <NUM> for storing and/or processing one or more configuration files <NUM>. The configuration file manager <NUM> is configured to receive and a configuration file <NUM> from a computer <NUM> or a server <NUM>, as discussed below in connection with <FIG>.

The configuration file manager <NUM> reads the configuration file <NUM> and configures the log manager <NUM>, the system health manager <NUM>, the device data manager <NUM>, the external agent <NUM>, the external interface <NUM>, the internal agent <NUM>, and/or the internal interface <NUM> as specified in the file <NUM>. For the log manager <NUM>, this may include writing a DCM identifier, medical device type, medical device identifier, etc. to registers, parameters/ or variables of the log manager <NUM>. For the system health manager <NUM>, that may include specifying parameters/attributes of the memory devices <NUM>, <NUM> and/or a processor/CPU of the DCM <NUM> to monitor. For the internal agent <NUM>, this may include specifying a data type for conversion.

In some instances, the configuration file manager <NUM> may also specify a conversion file type for the external agent <NUM>. Further, the configuration file manager <NUM> configures the device data manager <NUM> based on a duration between snapshots, types of medical device data to be included in the separate streams and/or subsets <NUM>, <NUM> and/or a type of data that is to be received from the medical device <NUM> (e.g., JSON data, HTML data, binary data, HL7 data, XML data, etc.). The configuration file manager <NUM> also reads the configuration file <NUM> to specify network credentials, authentication information, encryption keys, API identifiers, destination IP addresses, etc. for the external interface <NUM> and the internal interface <NUM>.

The configuration file manager <NUM> may also define or otherwise provide a user interface that enables a user of the computer <NUM> or the server <NUM> to view and/or modify a stored configuration file <NUM>. The user interface may include fields for configuring a network connection of the DCM <NUM>, specifying an identifier of the DCM <NUM>, specifying a username/password to access the DCM <NUM>, specifying parameters of the configuration file <NUM>, and/or installing software, such as a connectivity client or application.

<FIG> is a diagram showing the configuration file <NUM> of <FIG> being installed on the DCM <NUM> via the computer <NUM>, according to an example embodiment of the present disclosure. In this example, the computer <NUM> connects directly to the DCM <NUM> via an Ethernet, serial, or USB connection. The computer <NUM> may be operated by a hospital technical or technical associated with the manufacturer of the medical device <NUM>.

After connecting, the DCM <NUM>, via the configuration file manager <NUM>, launches an interface for display on the computer <NUM>. During this time, an operator of the computer <NUM> may edit and/or enter information into fields of the user interface related to configuration, network, software, and/or security. Further, the computer <NUM>, via the configuration file manager <NUM> is configured to enable an operator to specify parameters or attributes of a configuration file <NUM>. After the parameters and/or attributes are specified, the computer <NUM> transmits the configuration file <NUM> to the DCM <NUM>. The configuration manager <NUM> receives the configuration file <NUM> and provisions or otherwise configures the DCM <NUM> accordingly.

<FIG> shows a diagram where a server <NUM> installs the configuration file <NUM> on the DCM <NUM>. In this example, the DCM <NUM> may be configured at a time of manufacture with an IP address of the server <NUM>. The DCM <NUM> may also be configured with credentials and/or network settings for accessing the medical network <NUM> and/or information related to the medical device <NUM>, such as device type. After the DCM <NUM> is powered, the DCM <NUM> transmits a request message to the server <NUM> requesting the configuration file <NUM>. The request message may include authentication and/or validation information and/or an IP address of the DCM <NUM>. The server <NUM> may store one or more different types of configuration files based on hospital network and/or local configuration preferences. The server <NUM> determines which configuration file is assigned to the DCM <NUM>, based for example on a type of the medical device <NUM>, the medical network <NUM>, etc..

In response, after validating, the server <NUM> transmits the selected configuration file <NUM> to the DCM <NUM> via the external network <NUM> and the medical network <NUM>. The DCM <NUM> receives the configuration file <NUM>, which is used by the configuration file manager <NUM> of <FIG> to provision or otherwise configure the DCM <NUM>. The configuration shown in <FIG> enables automatic configuring of the DCM <NUM> without a technician or direct connection to a computer. In some embodiments, the server <NUM> may include the analytics server <NUM> of <FIG>.

<FIG> shows a diagram that is illustrative of the parameters and/or attributes of the configuration file <NUM> that are selectable by an operator at the computer <NUM> of <FIG> or specified by the server <NUM> of <FIG>, according to an example embodiment of the present disclosure. The configuration file <NUM> includes a parameter for medical device type <NUM>. Selection of a medical device type provides an indication of a type and/or format of medical device data that is to be received. Selection of the medical device type parameter <NUM> may also cause the DCM <NUM> to install one or more drivers for processing data from that medical device type. It should be appreciated that the drivers may be stored on the DCM <NUM> and only installed when the corresponding device type parameter is selected.

The configuration file <NUM> also includes an input port type parameter <NUM>. Selection of the input port type parameter <NUM> provides an indication as to which input ports of the DCM <NUM> are to be provisioned and/or activated. The DCM <NUM> may also install one or more drivers for the selected input port that specify how data from the medical device is converted, for example, in to a standardized JSON format. The configuration file <NUM> further includes parameters for the external interface <NUM> and parameters for the internal interface <NUM>. This includes 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 <NUM> that should be provisioned and/or activated.

The configuration file <NUM> further includes parameters for DCM information <NUM>, such as identification information, IP or network address, snapshot period, memory device persistence information, health statistics to monitor, etc. The DCM information parameters <NUM> may further include external address and/or credentials for accessing the analytics server <NUM> and internal address and/or credentials for accessing the EMR server <NUM>.

In some embodiments, the configuration file manager <NUM> may display an interface that is similar to the parameters shown in <FIG>. A user may select a parameter simply by selecting the corresponding button or entering information into a displayed field. In other embodiments, the configuration file may be text based, XML-based, and/or JSON-based, with the parameters being specified in certain sections of the file or identified by relevant data labels/fields. It should be appreciated that the configuration file <NUM> enables data transmission to an external server from virtually any medical device type in any desired format without having to make changes to a medical device or network infrastructure.

<FIG> is a diagram of the DCM <NUM> including input ports <NUM>, output ports <NUM>, and a processor <NUM> that includes one or more applications described above in connection with <FIG> for processing medical device data, according to an example embodiment of the present disclosure. In the illustrated example, the input ports <NUM> are operational with the device data manager <NUM> to communicatively couple to a medical device <NUM>. The inputs ports <NUM> can include one or more serial ports, Ethernet ports, Wi-Fi ports, Bluetooth® ports, or USB ports. It should be appreciated that the DCM <NUM> may include fewer ports. The configuration file <NUM> specifies which of the ports are activated for communication with the medical device <NUM>, including installation of the appropriate drivers.

Similarly, the DCM <NUM> includes output ports <NUM> for connection to the analytics server <NUM> and the EMR server <NUM> via the hospital network <NUM>. In the illustrated example, the output ports <NUM> are operational with the interfaces <NUM> and <NUM> to communicatively couple to the analytics server <NUM> and the EMR server <NUM>. The output ports <NUM> can include one or more serial ports, Ethernet ports, Wi-Fi ports, and/or cellular ports. It should be appreciated that the DCM <NUM> may include fewer or more output ports. The configuration file <NUM> specifies which of the ports are activated for communication with the medical device <NUM>, including installation of the appropriate drivers.

The example processor <NUM> specifies one or more instructions that perform the operations described in connection with <FIG>. The processor <NUM> includes an input module <NUM> that includes the device data manager <NUM> and medical device drivers <NUM>. The example device drivers <NUM> are installed based on which type of medical device <NUM> is used with the DCM <NUM>. Each driver includes instructions regarding how the data from the medical device is formatted or structured, which enables the device data manager <NUM> to identify the different data types for patient de-identification or inclusion in the first and second data streams or subsets <NUM>/<NUM>.

The example processor <NUM> also includes the external agent <NUM>, described above, and an encryption module <NUM> that is operational with the interface <NUM>. The processor <NUM> further includes the internal agent <NUM> and another encryption module <NUM> that is operational with the interface <NUM>. Additionally, the processor <NUM> includes the configuration file manager <NUM> for configuring the DCM <NUM> as specified by a configuration file <NUM>.

The processor <NUM> moreover includes a data conversion module <NUM>. The example data conversion module <NUM> is configured to convert medical device data from a first format to a second format, as specified by the configuration file <NUM>. The different data types of the data conversion module <NUM> define how data is converted from different formats into the specified second format, such as HL7, binary v2, binary v3, and/or FHIR. In some embodiments, the module <NUM> may include sections for JSON, XML, HTTP, HTML, etc..

The example DCM <NUM> of <FIG> may be configured as an IoT agent that provides secure, bi-directional connectivity from the DCM to the analytics server <NUM> by leveraging an IoT framework. The DCM <NUM> may use the IoT framework for device management, configuration, security, and transmission of connectivity health statistics. In some examples, the DCM <NUM> is configured with an IoT device shadow for the analytics server <NUM> for conveying the de-identified first data stream or subset <NUM> and/or the log/health data <NUM>.

The processor <NUM> may comprise digital and analog circuity structured as a microprocessor, application specific integrated circuit ("ASIC"), controller, etc. For example, the processor <NUM> may include a Digi ConnectCore® 6UL module, which has a NXP i. MX6UL-<NUM>, Cortex-A7 <NUM> CPU and <NUM> MB/<NUM> GB NAND and DDR3 flash drives. The DCM <NUM> also includes an <NUM>. 11a/b/g/n/ac Wi-Fi radio and a Bluetooth® <NUM> radio connected to the corresponding input ports <NUM> and/or output ports <NUM>. The processor <NUM> of the DCM <NUM> may be configured to operate with a Yocto Linux operating system and contains drivers for the Digi chipset. The processor <NUM> may operate a connectivity application that enables users to manage network and configuration settings via the configuration file manager <NUM>. The connectivity application also permits the DCM <NUM> to receive remotely provided software and firmware updates.

<FIG> is a flow diagram of an example procedure <NUM> for configuring the DCM <NUM> with a configuration file <NUM>, according to an example embodiment of the present disclosure. Although the procedure <NUM> is described with reference to the flow diagram illustrated in <FIG>, it should be appreciated that many other methods of performing the steps associated with the procedure <NUM> 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 blocks described may be optional. In an embodiment, the number of blocks may be changed. Further, the step of transmitting a confirmation of a reception of a configuration file <NUM> may be omitted. The actions described in the procedure <NUM> are specified by one or more instructions and may be performed among multiple devices including, for example, the DCM <NUM>, the computer <NUM>, and/or the server <NUM>.

The example procedure <NUM> begins in <FIG> when the DCM <NUM> receives or otherwise acquires a configuration file <NUM> (block <NUM>). In some embodiments, the configuration file <NUM> may be created locally at the DCM <NUM> via a user interface provided by the configuration file manager <NUM>. After acquiring, the DCM <NUM> stores the configuration file (block <NUM>). The DCM <NUM> next reads the configuration file <NUM> to determine which parameters/attributes are specified. Based on the specified parameters/attributes, the DCM <NUM> accesses and installs the corresponding device drivers for processing data from a specified medical device type (block <NUM>).

The example DCM <NUM> also provisions one or more input ports of an input interface for communication with a medical device <NUM> based on the specified parameters/attributes of the configuration file <NUM> (block <NUM>). The example DCM <NUM> further provisions one or more output ports of an output interface for communication with the analytics server <NUM> based on the specified parameters/attributes of the configuration file <NUM> (block <NUM>). Additionally, the example DCM <NUM> provisions one or more output ports of the output interface for communication with the EMR server <NUM> based on the specified parameters/attributes of the configuration file <NUM> (block <NUM>). Provisioning the input/output ports may include activating identified input and output ports and installing any related drivers.

In addition to above, the DCM <NUM> provisions a data manager to covert medical device data from a medical device into a format specified by the configuration file <NUM> for transmission to the EMR server <NUM> (block <NUM>). In some instances, the DCM <NUM> provisions the data manager to convert medical device data into a standardized format for processing by the analytics server <NUM>. The DCM <NUM> may then complete the configuration process by transmitting a confirmation message <NUM> that is indicative of the configuration to, for example, the computer <NUM> or the server <NUM> of <FIG>, respectively (block <NUM>). The example procedure <NUM> then ends and the DCM <NUM> is ready to process medical device data.

<FIG> is a flow diagram of an example procedure <NUM> for processing medical device data with the DCM <NUM>, according to an example embodiment of the present disclosure. Although the procedure <NUM> is described with reference to the flow diagram illustrated in <FIG>, it should be appreciated that many other methods of performing the steps associated with the procedure <NUM> 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 blocks described may be optional. In an embodiment, the number of blocks may be changed. Further, the step of encrypting data subsets may be omitted. The actions described in the procedure <NUM> are specified by one or more instructions and may be performed among multiple devices including, for example, the DCM <NUM>, the medical device <NUM>, the analytics server <NUM>, and/or the EMR server <NUM>.

The example procedure <NUM> begins when the DCM <NUM> receives medical device data <NUM> from a communicatively coupled medical device <NUM> (block <NUM>). The DCM <NUM> records a snapshot of the received data based on a periodic interval and creates two separate data streams or subsets (block <NUM>). In some instances, the same medical device data is used for each subset. In other instances, the data subsets may include different and some of the same medical device data.

For a first data stream or subset, the DCM <NUM> de-identifies the data to create de-identified data <NUM> (block <NUM>). This includes removing any data that may be used to identify a patient. In some instances, patient identifiers are replaced with session identifiers and/or a random character set. The DCM <NUM> then adds log/health data <NUM> to the de-identified data <NUM> (block <NUM>). The DCM <NUM> may then encrypt the de-identified data <NUM> and/or the log/health data (block <NUM>).

The DCM <NUM> then checks if a connection to the analytics server <NUM> exists (block <NUM>). In some instances, the DCM <NUM> may use a Message Queuing Telemetry Transport ("MQTT") messaging protocol to check a connection status. If a connection does not exist, the DCM <NUM> stores one or more encrypted messages with the de-identified data <NUM> and/or the log/health data <NUM> to a persistent memory device (block <NUM>). The DCM <NUM> continues to store subsequent encrypted messages until a data connection is detected. Once a data connection is detected, the DCM <NUM> transmits the encrypted messages including the de-identified data <NUM> and/or the log/health data <NUM> to the analytics server <NUM> via one or more networks <NUM>, <NUM> (block <NUM>). The example procedure <NUM> then returns to block <NUM> for processing newly received medical device data.

For the second stream or subset of medical device data, the DCM <NUM> converts the data into a format that is specified for the EMR server <NUM> (block <NUM>). This may include converting medical device data in a JSON format, an HL7 format, a binary version <NUM>/<NUM> format, an FHIR format, an XML format, and/or an HTTP format. The DCM <NUM> may then add log/health data <NUM> to the converted data <NUM> (block <NUM>). The DCM <NUM> may then encrypt the converted data <NUM> and/or the log/health data <NUM> (block <NUM>).

The DCM <NUM> then checks if a connection to the EMR server <NUM> exists (block <NUM>). In some instances, the DCM <NUM> may use a MQTT messaging protocol or a Minimum Lower Layer Protocol ("MLLP") to check a connection status. If a connection does not exist, the DCM <NUM> stores one or more encrypted messages with the converted data <NUM> and/or the log/health data <NUM> to a persistent memory device (block <NUM>). The DCM <NUM> continues to store subsequent encrypted messages until a data connection is detected. Once a data connection is detected, the DCM <NUM> transmits the encrypted messages including the converted data <NUM> and/or the log/health data <NUM> to the EMR server <NUM> via the medical network <NUM> and/or a serial connection (block <NUM>). The example procedure <NUM> then returns to block <NUM> for processing newly received medical device data.

Claim 1:
A digital communication apparatus (<NUM>) comprising:
an input interface (<NUM>) configured for communicative coupling to a medical device (<NUM>), the input interface including a serial input port, an Ethernet input port, and a wireless input port;
an output interface (<NUM>) configured for communicative coupling to a medical network (<NUM>), 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 (<NUM>) and drivers (<NUM>) for the input and output ports; and
a processor (<NUM>) communicatively coupled to the input interface, the output interface, and the memory device, the processor configured to:
receive a configuration file (<NUM>) from an administration computer via the output interface, the configuration file (<NUM>) 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,
store the configuration file to the memory device,
identify the input port and the at least one output port as specified by the configuration file,
install drivers for the identified input and output ports specified by the configuration file,
provision the input interface with the specified input port to receive medical data (<NUM>) from the medical device in the first data format, and
provision the output interface with the at least one specified output port to transmit at least some of the received medical data (<NUM>, <NUM>) using the first data format and the second data format.