Method for data communication between an infusion station and a front-end computing device in a healthcare environment

Abstract

In a method for data communication between an infusion station (1) and a front-end computing device (2) in a healthcare environment, at least one infusion station (1) for performing an infusion operation sends data in an upstream direction (A1) and receives data in a downstream direction (A2). In addition, at least one front-end computing device (2) receives data in an upstream direction (A1) and sends data in a downstream direction (A2). In this context, driver modules (DP1 to DP4) receive data from at least one infusion station (1) in an upstream direction (A1) and send data to at least one infusion station (1) in a downstream direction (A2), and virtual device modules (VD1, VD2) send data to at least one front-end computing device (2) in an upstream direction (A1) and receive data from at least one front-end computing device (2) in a downstream direction (A2).

Description

Technical Field

[0001] The present invention relates to a method for data communication between an infusion station and a front-end computing device in a healthcare environment, and to a system for data communication in a healthcare environment. Background Art

[0002] In this method, at least one infusion station for performing an infusion operation sends data in an upstream direction or receives data in a downstream direction. A front-end computing device receives data related to the at least one infusion station in an upstream direction or sends data related to the at least one infusion station in a downstream direction.

[0003] The infusion station can be, for example, an independent infusion pump, such as a volumetric (peristaltic) infusion pump or a syringe infusion pump. Alternatively, the infusion station can be an arrangement of multiple infusion pumps, such as infusion pumps stacked on a rack.

[0004] Typically, a user may wish to initiate data communication with one or more infusion stations including one or more infusion pumps, for example to monitor an ongoing infusion operation or to program an infusion pump to perform an infusion operation. To this end, the user may access a front-end computing device such as a computing device in the form of a PC, laptop or tablet computer or a communication device such as a mobile phone, etc., connected to a communication network to receive data from or send data to the pump device.

[0005] Conventionally, a direct data path between the front-end computing device and the infusion station is established, and such a direct data path is characterized by data transmission using a defined protocol. Different pump devices herein may use different communication protocols, and the communication protocol used for data transmission may also depend on a specific communication channel, such as a communication channel for wired communication (e.g., Ethernet / LAN) or for wireless communication (e.g., WiFi). Different protocols herein may define different data structures, so that the use of different protocols brings about the following effect: data of different devices are presented differently in different structures and may have different contents. Therefore, if a user wishes to connect to an infusion station via a front-end computing device, it should be ensured that the front-end computing device is able to communicate with a specific infusion station, which may require updating the front-end computing device to install a software application that allows communication using the specific communication protocol required by the infusion station.

[0006] Because there are a variety of different infusion stations with different types (e.g., volumetric (peristaltic) infusion pumps or syringe infusion pumps), different families (e.g., infusion pumps belonging to one manufacturer but of a specific different brand), and different manufacturers of pump devices, it can be a cumbersome task to keep front-end computing devices, for example in a healthcare environment such as a hospital, updated so that they can communicate with the infusion stations placed throughout the healthcare environment.

[0007] In particular, if a new device is used in a hospital environment, it may be necessary to install appropriate software updates on each individual front-end device that may communicate with the new device.

[0008] WO 2014 / 131729 A2 describes a system for providing drug library data to a medical device located in a healthcare environment, the system comprising a local network and at least one medical device for administering a drug to a patient, the at least one medical device being located in the healthcare environment and connected to the local network. The drug library data herein is transmitted to the at least one medical device via a public communication network. Summary of the invention

[0009] The object of the present invention is to provide a method for data communication between an infusion station and a front-end computing device and a system for data communication in a healthcare environment, which allows facilitating data communication between one or more infusion stations and a front-end computing device while making the execution of the device in the healthcare environment easier.

[0010] This object is achieved by a method according to an embodiment of the present invention.

[0011] Herein, the method further comprises the following steps: the driver module performs at least one of receiving data from at least one infusion station in an upstream direction and sending data to at least one infusion station in a downstream direction; and the virtual device module performs at least one of sending data to at least one front-end computing device in an upstream direction and receiving data from at least one front-end computing device in a downstream direction. The driver module herein is configured to perform at least one of the following operations: processing data received from at least one infusion station in an upstream direction to provide the data to the virtual device module, and processing data received from the virtual device module in a downstream direction to send the data to at least one infusion station. In addition, the virtual device module includes a data model defining a plurality of data structures in which data related to at least one infusion device is stored.

[0012] The driver module and the virtual device module can be hosted, for example, on a server system, such as a back-end server in a healthcare environment, such as a hospital. The server system herein may include a single server unit or may include a plurality of distributed servers that together constitute a server system. The driver and the virtual device module herein may reside on the same physical server, or may be hosted on different distributed servers.

[0013] An intermediate layer between the infusion station and the front-end computing device is introduced through the driver and virtual device modules, and the intermediate layer prepares for the conversion and abstraction in the communication between the infusion station and the front-end computing device.

[0014] In particular, the driver module is used to prepare for communication with one or more infusion stations, wherein the infusion station may include one or more different pump devices of different types, and the different pump devices use different protocols to transmit data. The driver module - in particular managing the connection with the infusion station - is able to communicate using the communication protocol required by the specific infusion station and is therefore able to process data received from the infusion station and data sent to the infusion station using the specific communication protocol associated with the infusion station.

[0015] The virtual device module is also prepared for communication with one or more front-end computing devices, so that the front-end computing device always communicates with the virtual device module. This makes it possible to use a defined public protocol or protocol set for data communication between the virtual device module and any front-end computing device.

[0016] The virtual device module includes a data model defining a plurality of data structures. In the data model, data processed by the driver module is stored in defined dedicated data structures such that data received from one or more infusion devices is organized in the defined structures according to the data structures of the data model. In the virtual device module, data associated with the one or more infusion devices is thus organized in a structure that is independent of a communication protocol by which the data is transmitted between the one or more infusion devices and the driver module.

[0017] The organization of data associated with one or more infusion devices in a data model included in a virtual device module allows for communication with one or more front-end computing devices using a common communication protocol. In particular, data can be transmitted from the virtual device module to the one or more front-end computing devices using a common communication protocol that is independent of any communication protocol via which data is transmitted between the infusion device and the virtual device module.

[0018] Thus, data communication between the front-end computing device and the virtual device module is independent of any data communication between the infusion device and the virtual device module (via one or more driver modules). Through the virtual device module, a common data model is provided that allows data transmission between the front-end computing device and the virtual device module. Data can be exchanged between the virtual device module and the front-end computing device using a common communication protocol, which is independent of data communication between the driver module and the associated infusion device (involving a specific communication protocol for data communication).

[0019] By introducing an intermediate layer including one or more driver modules and one or more virtual device modules, the execution of devices in a healthcare environment is facilitated to enable communication between different devices, since no adaptation of software components on a front-end computing device is required if, for example, a new infusion station implementing a specific communication protocol is added. The front-end computing device communicates with the one or more virtual device modules using a defined common protocol or set of protocols defining data exchange between the virtual device modules and the front-end computing device, such communication being unaffected by the addition of a new infusion station to the system.

[0020] Conversely, if a new infusion station that requires a specific communication protocol is added to the system, only a suitable new driver module needs to be installed, for example, on the back-end server, without having to modify the front-end computing device to enable communication. The driver modules herein enable data to be exchanged between the infusion station and the corresponding virtual device module, and the driver modules provide for the processing of data both in the upstream direction toward the virtual device module and in the downstream direction toward the infusion station.

[0021] In one embodiment, different drivers can communicate with different infusion stations using different first communication protocols. In particular, there may be different kinds of infusion stations, including, for example, pump devices of different types (e.g., volumetric infusion pumps or syringe infusion pumps) and belonging to different device families (e.g., Fresenius is currently providing pump devices in the so-called Agilia family and other pump devices for enteral feeding in the so-called Amika family). In addition, an infusion station consisting of, for example, independent pump devices or a stack of pumps combined on, for example, a rack can communicate using different communication channels, such as wireless communication channels using Wi-Fi or wired communication channels using, for example, Ethernet connections. In this article, for each protocol being used by any infusion station, there can be a driver and the driver can be installed on, for example, a server system, so that the driver module implements communication between an infusion station using the protocol and a corresponding virtual device module, so that data can be exchanged between the infusion station and the virtual device module.

[0022] Thus, there may be, for example, a first driver module for communicating with the infusion station using a first communication channel such as a wired communication channel, for example an Ethernet connection. Such a driver module may enable, for example, communication using an Ethernet protocol. There may be a second driver module for communicating with the infusion station using a second communication channel, for example a wireless communication channel, enabling communication using a Wi-Fi (Wireless LAN) protocol, a Bluetooth protocol, an NFC (Near Field Communication) protocol, etc. For infusion stations of different types and, for example, belonging to different device families, there may be a third driver module. In general, a driver module may be provided for each communication channel between the infusion station and the corresponding virtual device module using a specific communication protocol.

[0023] In one embodiment, the first communication protocol can be based on WiFi, HTTP or Ethernet. Such protocols can be standardized. WiFi protocols are standardized, for example, in the IEEE 802.11 standard. Ethernet protocols are standardized in the IEEE 802.3 standard. In addition, based on the standardized protocols, proprietary modifications implemented by the pump manufacturer can be adopted, so that in addition to the standardized protocol schematics, the protocol used by a specific infusion station can also adopt a proprietary scheme.

[0024] The second communication protocol used for communication between the virtual device module and one or more front-end computing devices can be different from the first communication protocol, or can be the same. For example, the second communication protocol can be based on AMQP or HTTP. In this article, a common communication protocol can be used for communication between the front-end computing device and one or more virtual device modules, and the common second communication protocol is independent of any communication protocol used for communication between the infusion device and the associated driver module.

[0025] Although there are different driver modules for different infusion stations, and different driver modules use different communication protocols to communicate with different infusion stations, the communication between the virtual device module and one or more front-end computing devices is performed using a common protocol scheme, so that all front-end computing devices use the same communication protocol or communication protocol set to communicate with the virtual device module. Therefore, if the driver module is modified or added, the communication between the front-end computing device and the virtual device module is not affected.

[0026] In one embodiment, the virtual device module uses an upstream protocol as the second communication protocol in the upstream direction and uses a downstream protocol different from the upstream protocol as the second communication protocol in the downstream direction. Thus, different protocols are used depending on whether the communication is performed in the upstream direction or in the downstream direction.

[0027] However, the upstream protocol may be based on AMQP, for example, and the downstream protocol may be based on HTTP, for example.

[0028] Such use of different protocols in the upstream direction and in the downstream direction is based on the fact that the virtual device module, in one embodiment, should use a data structure defined by the data model to store data received from one or more infusion stations or from one or more front-end communication devices in the data model. In particular, the virtual device module can store data related to the identity of the pump device of the infusion station, the status of the pump device of the infusion station, and the capabilities of the pump device of the infusion station in an associated predefined data structure. Therefore, the virtual device module merges the data related to the pump device and stores the data in a structured general data model in an organized manner, so that the virtual device module can be accessed by one or more front-end computing devices to obtain, modify or transmit information related to a specific pump device or a specific infusion station including multiple pump devices.

[0029] Herein, in one embodiment, the structure of the data model is independent of the virtual device module, and different virtual device modules use the same general data model with the same structure.

[0030] In the data model, data may be stored using, for example, XML (Extensible Markup Language).

[0031] For transferring data between the driver module and the associated virtual device module, a protocol allowing data buffering may be employed, in particular AMQP (AMQP stands for Advanced Message Queuing Protocol), which is an open standard application layer protocol for message-oriented middleware and allows queuing of data messages.

[0032] In particular, the virtual device module may store information related to the identity of the pump device in the data model, such as the family of the pump device, the type of the pump device, and the version of hardware or software currently installed on the pump device.

[0033] Additionally or alternatively, the virtual device module can store information related to the pump status in the data model, such as the connectivity of the pump device, the infusion status of an ongoing infusion operation, the location of the pump device on a rack, and the location of the pump device in a healthcare environment such as a hospital. The information related to the infusion status can include the drug, dose, dose rate, infusion time, remaining infusion time, patient information, etc. of the infusion operation.

[0034] Additionally or alternatively, the virtual device module may store information related to the capabilities of the pump device in the data model, wherein the capabilities may depend on a communication channel through which the pump device is connected to the communication network and is therefore able to communicate with the corresponding driver module. In particular, the capabilities may include clinical functions that are available depending on the communication channel through which the pump device is connected. For example, if the pump device is connected via a wireless communication channel, only a portion of the clinical functions may be available compared to other communication channels such as wired communication channels. Such clinical functions may, for example, involve automatic programming, automatic documentation, drug library configuration, technical configuration, firmware upload, and device event logs associated with the pump device. For example, firmware upload may only be available for a wired communication channel, but not if the pump device is connected via a wireless communication channel.

[0035] For the predefined categories of information herein, predefined data structures may exist in a data model included in the virtual device module, such that information related to the infusion device is stored in the predefined data structure, which is independent of any communication protocol used to transmit data between the infusion device and an associated driver module.

[0036] In one embodiment, the driver module is implemented as a dynamic link library (abbreviated as: dll) or a windows service. A dynamic link library represents a shared library that can be used by software applications. Such a dynamic link library allows executable programming code that can be jointly executed by different applications to be provided in a modular manner. Dynamic link libraries with files ending in .dll are particularly used in windows operating system environments.

[0037] In one embodiment, the virtual device module groups infusion devices of an infusion station belonging to a common device family. In this context, one virtual device module may be installed for each device family, so that there is one virtual device module for each family. In the virtual device module, information related to pump devices belonging to the same family but possibly of different types (e.g., volumetric infusion pumps and syringe infusion pumps) may be stored and accessed by the front-end computing device.

[0038] For data communication between the driver module and the corresponding virtual device module, a common protocol such as AMQP can be used, wherein each driver module communicates with the corresponding virtual device module using the same protocol. In this article, one virtual device module can communicate with different driver modules, i.e., one driver module for each protocol being used by the pump device of the device family.

[0039] The object is also achieved by a system for data communication in a healthcare environment, the system comprising: at least one infusion station for performing an infusion operation, the at least one infusion station being configured to perform at least one of sending data in an upstream direction and receiving data in a downstream direction; and at least one front-end computing device being configured to perform at least one of receiving data related to the at least one infusion station in an upstream direction and sending data related to the at least one infusion station in a downstream direction. The system also includes a server system hosting a driver module and a virtual device module, the driver module being configured to perform at least one of receiving data from the at least one infusion station in an upstream direction and sending data to the at least one infusion station in a downstream direction, and the virtual device module being configured to perform at least one of sending data to the at least one front-end computing device in an upstream direction and receiving data from the at least one front-end computing device in a downstream direction. In this context, the driver module is configured to perform at least one of the following operations: processing data received from the at least one infusion station in an upstream direction to provide the data to the virtual device module, and processing data received from the virtual device module in a downstream direction to send the data to the at least one infusion station using the first communication protocol. The virtual device module includes a data model defining a plurality of data structures in which data associated with at least one infusion device is stored.

[0040] The advantages and advantageous embodiments described above for the method also apply to the system, so that reference is made to the above in this respect. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The underlying concepts of the present invention will be described in more detail later with reference to the embodiments shown in the accompanying drawings. In this context:

[0042] Figure 1 A schematic diagram of a system for data communication in a healthcare environment is shown;

[0043] Figure 2 shows data communication between an infusion station and a front-end computing device using direct communication;

[0044] Figure 3 The communication between the infusion station and the front-end computing device using an intermediate layer is shown, and the intermediate layer includes a driver module and a virtual device module for converting and abstracting data communication between the infusion station and the front-end computing device;

[0045] Figure 4 A schematic diagram showing a data model including a data structure for storing data in a virtual device module in an organized manner; and

[0046] Figure 5 A schematic diagram of a data structure including substructures is shown. DETAILED DESCRIPTION

[0047] Figure 1 A schematic diagram shows a setup that can be found in a healthcare environment, such as a hospital. That is, in a healthcare environment, an infusion station 1, such as a stack of pump devices 11 placed on a rack 10 in an organized manner or a stand-alone pump device 12, can be connected to a hospital communication network 4 and via the communication network 4 to a hospital information system (HIS). In addition, a front-end computing device 2, such as a stationary personal computer (PC), a laptop, a tablet computer, or a mobile communication device such as a mobile phone is connected to the communication network 4. A server system 3, in particular a back-end server comprising one or more (distributed) physical server entities, is connected to the communication network 4, which enables data exchange between the infusion station 1, the front-end computing device 2 and the server system 3.

[0048] In the context of a healthcare environment, a user may wish to set up an infusion operation to be performed by one or more pump devices 11, 12, such pump devices 11, 12 being arranged throughout the healthcare environment, in different wards and different rooms, at the bedside of different patients. To this end, a user may wish to transfer programming data to one or more pump devices 11, 12 in order to set up an infusion operation, or to manage and perform configuration of one or more pump devices 11, 12, for example by transferring drug library data to one or more pump devices 11, 12, such drug library data providing general boundaries and guidelines for setting up an infusion operation, such as boundaries for a dose rate of a particular drug, etc.

[0049] Additionally, the user may wish to monitor ongoing infusion operations performed by one or more pump devices 11, 12, which requires data transmission from the pump devices 11, 12 to the front-end computing device 2, via which the user may access the data.

[0050] Now refer to Figure 2 , conventionally, infusion station 1 - e.g. Figure 1 The data exchange between the schematically indicated pump device 11 or the independent pump device 12 placed on the rack 10 and the front-end computing device is carried out by direct data transmission via communication channels C1 to C4, each communication channel C1 to C4 using, for example, a dedicated protocol P1 to P4 to send data from the infusion station 1 to the front-end computing device 2, for example in the upstream direction A1. Figure 2 shown.

[0051] The first communication channel C1 herein may be, for example, a wireless channel according to the Wi-Fi protocol and additionally using the HTTP protocol for data transmission, for connecting the infusion station 1 having a pump device belonging to the first type D1 and the first family F1 to the front-end computing device 2. The same infusion station 1 herein may alternatively or additionally use a second communication channel C2, which may be, for example, a wired channel, such as an Ethernet channel following the Ethernet protocol.

[0052] An infusion station 1 having a pump device of a different type D2 but belonging to the same family F1 can use a third communication channel C3 which is for example also a wired channel but uses a different protocol P3.

[0053] Another infusion station 1 having a pump device of type D1 but of a different family F2 can use a communication channel C4 , which likewise uses a different protocol P4 , to communicate with the front-end computing device 2 .

[0054] The pump type D1, D2 herein may indicate whether the pump device is a volumetric (peristaltic) infusion pump, a syringe infusion pump, or another type of pump.

[0055] The device families F1 and F2 may be defined by a brand of a certain manufacturer, and devices of the same family F1 and F2 generally use similar infrastructure, such as similar operating software.

[0056] Typically, depending on which channel C1 to C4 is used to transmit the data, the data messages m1 to m3 are transmitted according to the specifications of a specific protocol P1 to P4, which is used to package the data messages m1 to m3 according to the limitations of the protocol. In this article, in the upstream direction A1, each front-end computing device 2 needs to understand the specific protocol P1 to P4 used by the infusion station 1 in order to unpack the data messages m1 to m3 for outputting the data contained in such messages m1 to m3 to a user who wishes to access the infusion station 1, for example, to monitor the ongoing infusion operation. In the downstream direction A2 towards the infusion station 1, data transmission is performed in a similar manner, with each front-end computing device 2 transmitting data to the infusion station 1 via a specific communication channel C1 to C4 using a specific protocol P1 to P4.

[0057] Therefore, in Figure 2 In a conventional setup of FIG. 1 , each front-end computing device 2 needs to be able to communicate using a specific protocol P1 to P4 in order to be able to communicate with the infusion station 1. If an infusion station 1 using a new pump device employing a different protocol is added to the system, this may require updating all front-end computing devices 2, which may be cumbersome and generally makes the communication setup difficult to perform.

[0058] Now refer to Figure 3It is proposed herein to introduce an intermediate layer between the infusion station 1 and the front-end computing device 2, such an intermediate layer being hosted on a server system 3, for example, a back-end server comprising one or more (distributed) server entities in a healthcare environment.

[0059] The introduction of the middle layer is generally based on the idea of ​​using a modular communication setup to provide conversion and abstraction between the infusion station 1 and the front-end computing device 2. Both the infusion station 1 and the front-end computing device 2 herein should communicate only with the middle layer, so that direct data transmission from the infusion station 1 to the front-end computing device 2 and from the front-end computing device 2 to the infusion station 1 are no longer required, so that the front-end computing device 2 does not necessarily have to be able to communicate according to the protocols P1 to P4 used by a specific infusion station 1 for a specific communication channel C1 to C4.

[0060] The middle layer includes driver modules DP1 to DP4 for preparing for communication with the infusion station 1. In addition, virtual device modules VD1, VD2 are installed, which are configured to prepare for data exchange with the front-end computing device 2.

[0061] The driver modules DP1 to DP4 may be implemented, for example, by so-called dynamic link libraries (.dll files), which provide, for example in the Microsoft Windows operating system environment, dynamically linkable libraries of executable software codes that can be employed by different software applications. Each communication channel C1 to C4 using a specific protocol P1 to P4 is associated with a specific driver module DP1 to DP4 herein, each driver module DP1 to DP4 being able to provide for communication using a specific protocol P1 to P4.

[0062] That is to say, Figure 3 In the example of FIG. 4 , a first channel C1 using a first protocol P1 is associated with a first driver module DP1 , the first channel C1 being used, for example, for wireless data communication.

[0063] A second communication channel C2 is associated with the second driver module DP2, the second communication channel C2 being for example a wired channel using a second protocol P2, for example an Ethernet channel according to the Ethernet protocol.

[0064] A third communication channel C3 using a third protocol P3 is associated with the third driver module DP3.

[0065] A fourth communication channel C4 using a fourth protocol P4 is associated with a fourth driver module DP4.

[0066] Each driver module DP1 to DP4 is configured to provide for data exchange with the infusion station 1 via a specific associated communication channel C1 to C4, the driver module DP1 to DP4 managing the connection and configured to process data communicated in the upstream direction A1 and in the downstream direction A2.

[0067] That is, in the upstream direction A1, the data received via the associated communication channels C1 to C4 are unpacked by removing the protocol frames used to transmit the messages m1 to m3. Such unpacked messages m1 to m3 are then forwarded to the associated virtual device modules VD1, VD2, such as Figure 3 In the virtual device modules VD1, VD2, as will be explained in more detail later, the data received from the driver modules DP1 to DP4 are stored in a defined data model M (see Figure 4 ) in which the data is organized in data structures M1, M10 to M19.

[0068] Conversely, in the downstream direction A2, each driver module DP1 to DP4 is configured to process data messages m1 to m3 received from the associated virtual device modules VD1, VD2 to package the data messages m1 to m3 using a defined protocol framework of the associated protocols P1 to P4, so that the data messages m1 to m3 are forwarded to the infusion station 1 using the specific protocol P1 to P4.

[0069] For the communication between the driver modules DP1 to DP4 and the virtual device modules VD1 , VD2 , a common protocol may be used, for example a protocol allowing queuing (buffering) of data messages, such as AMQP.

[0070] Typically, for example, in the context of an infusion operation, data for transmission from the infusion station 1 to the associated driver modules DP1 to DP4 and virtual device modules VD1, VD2 in the upstream direction A1 can be performed in a synchronous manner, for example, data transmission is performed in an event-triggered manner when a data event occurs. The intermediate layer including the driver modules DP1 to DP4 and the virtual device modules VD1, VD2 herein is configured to buffer and store data received from the infusion station 1 so that when they are requested by the user U, the stored data can be forwarded to the front-end computing device 2.

[0071] The virtual device modules VD1, VD2 are used to communicate with the front-end computing device 2, and the virtual device modules VD1, VD2 can be accessed by the front-end computing device 2 to provide data transmission to and from the infusion station 1. In this document, for each device family F1, F2, one virtual device module VD1, VD2 can be implemented to include a data model for the device family F1, F2. Figure 3In the example of FIG. 1 , the first device family F1 is associated with the virtual device module VD1 , and the second device family F2 is associated with the virtual device module VD2 .

[0072] The virtual device modules VD1 , VD2 are used in particular to store and consolidate in a data model M information relating to an infusion station 1 and a pump device of such an infusion station 1 .

[0073] In particular, in the virtual device modules VD1, VD2, information related to the identity of the pump of the associated device family F1, F2 can be stored, such information including information about the device family F1, F2, the pump type D1, D2 and the version of the pump device, such as the hardware version or the installed software version.

[0074] Alternatively or in addition, the virtual device modules VD1, VD2 may store information related to the pump status, such as connection status, infusion status, location of the pump device 11 on the rack 10, location of the pump devices 11, 12 in a healthcare environment such as a hospital, etc. The connection status may include whether the pump device is currently connected to the communication network 4, and if the pump device is currently connected to the communication network 4, via which channel C1 to C4 the connection is made. The infusion status may include whether an infusion operation is currently in progress, and if an infusion operation is in progress, which parameters are used for the infusion, such as the currently infused drug, the dose rate, the total dose, the infusion time, and the remaining time for the infusion.

[0075] Alternatively or in addition, the virtual device modules VD1, VD2 may store information related to pump capabilities, wherein the capabilities may be different for different communication channels C1 to C4, through which a particular infusion station 1 is connected to the communication network 4 and, therefore, to the server system 3. For example, for the wireless communication channel C1, there may be different capabilities than for the wired channels C2 to C4. Such capabilities may relate to clinical functions and their availability, such clinical functions including, for example, an automatic programming function, an automatic documentation function, a drug library configuration function, a technical configuration function of the pump device, a firmware upload function, and a device event log function. For example, firmware upload may only be possible when the infusion station is connected via the wired communication channels C2 to C4 and not via the wireless communication channel C1.

[0076] Now refer to Figure 4 Each virtual device module VD1, VD2 comprises a data model M, in which data relating to an infusion station 1 belonging to a device family F1, F2 associated with the virtual device module VD1, VD2 is stored in a predefined, specific, dedicated data structure M1, M10 to M19.

[0077] In this context, in the data model M of each infusion station 1 associated with a device family F1, F2, there is a data structure M1 comprising a substructure tree. In the data structure M1, information related to a specific infusion device is stored in dedicated structure elements.

[0078] In particular, in the first data structure M10, information relating to the virtual device modules VD1, VD2 with which the infusion station 1 is associated can be stored.

[0079] In the second data structure M11 , location information related to the infusion station 1 may be stored, such as information identifying the exact physical location of the infusion station 1 , such as information related to a hospital, a ward, a room and a patient's specific bed.

[0080] In the third data structure M12, information related to the infusion station 1 may be stored, for example information related to the pump type, pump family, pump model, etc.

[0081] In the fourth data structure M13, information related to the device status can be stored, which information is related to, for example, the status of the operating mode (such as "off", "standby", "start", "on", "error", "maintenance"), the status of the infusion operation (such as "programming in progress", "installation in progress", "infusing", "stop", "pause", "delayed infusion"), and information related to the battery status, etc. can be stored.

[0082] In the fifth data structure M14, information related to alarms, such as alarms and pre-alarms, may be stored.

[0083] In the sixth data structure M15, information related to a specific infusion may be stored. In the present document, in the data substructure M16, information related to a new prescription may be stored, and in the data substructure M17, information related to the current prescription may be stored. In the present document, in the substructure M18 related to the data structure M17, global infusion information and current infusion information may be stored in data structures M18, M19. In the present document, the data structure M18 related to the global infusion information may be associated with structural elements M180 to M182, in which structural elements M180 to M182 may be stored information related to the patient (e.g., the patient's name, weight, height, sex, and age), information related to the drug (e.g., drug concentration and dilution), and information related to the care area (e.g., intensive care unit).

[0084] In the substructure M19 (associated with the data structure M17 identifying information related to the current prescription), information related to the current infusion operation may be stored, such as Figure 5 , as shown in the illustrative example.

[0085] In particular, in the data structure M19, all information related to the currently ongoing infusion operation can be stored, such as information related to the programming mode (data structure M190, such as "time rate", "volume rate", "volume time", "volume time rate", "TCI", "ramp", "sequence"), information related to the delivery mode (data structure M191, such as "standard", "manual push", "programmed push", "simple push", "infusion"), information related to the flow rate (data structure M192), information related to the dose rate (data structure M193), information related to the prescribed amount (data structure M194), and information related to the dosage rate (data structure M195). structure M194), information related to the remaining amount (data structure M195), information related to the infusion amount (data structure M196), information related to the infusion dose (data structure M197), information related to the cause of delivery failure (data structure M198), information related to the dose completion status (data structure M199), information related to the remaining duration of the infusion operation (data structure M200), information related to the time until the end of the container from which the drug is drawn in the context of a sequential infusion operation (data structure M201), and information related to the remaining pause time (data structure M202).

[0086] Thus, in the data model M, defined pieces of information are stored in defined data structures. The information is extracted from the communication messages received from the infusion stations, the processing of which is performed by the driver modules DP1 to DP4, which forward the data to the virtual device modules VD1, VD2 for storage in the common data model M. The front-end computing device 2 can then exchange data with the data model M, so that information can be provided to the front-end computing device 2, and vice versa, information issued by the front-end computing device 2 can be stored in the data model M and transmitted to the relevant infusion station 1.

[0087] Now refer to Figure 3 The virtual device modules VD1 and VD2 use a common protocol or a set of protocols to communicate with the front-end computing device 2, wherein such a protocol or a set of protocols is not affected by the protocols P1 to P4 used for communicating with the infusion station 1.

[0088] For the communication between the virtual device modules VD1 and VD2 and the front-end computing device 2 in this article, different protocols can be used in the upstream direction A1 and the downstream direction A2. In the upstream direction A1, for example, a queuing protocol such as AMQP can be used. Conversely, in the downstream direction, the HTTP protocol can be used, for example, XML and / or JSON can be used in addition.

[0089] In this context, each virtual device module VD1, VD2 typically stores the data d1 to d5 extracted from the messages m1 to m3 received from the infusion stations 1 (where each infusion station 1 may send different messages containing different data) in a common data model, for example containing the pure data d1 to d5. If requested, the data is sent according to a defined protocol VD (defined by Figure 3 The data transmission VD (d1, d2, d3, d4, d5) in the embodiment of the present invention provides such data to the front-end computing device 2. In the downstream direction A2, data transmission is performed in a similar manner, wherein different protocols can be used for data exchange.

[0090] Similar to the data transmission from the infusion station 1 to the virtual device modules VD1, VD2, the data transmission from the computing device 2 to the virtual device modules VD1, VD2 can be performed in a synchronous, event-driven manner, for example, when the user U inputs information, for example, for programming the infusion station 1 and setting up the infusion operation. The virtual device modules VD1, VD2 store such information in the data model M, so that, for example, once communication is possible, for example, once the infusion station 1 is connected to the communication network 4 via specific communication channels C1 to C4, the information is transmitted to one or more infusion stations 1 in a buffered manner.

[0091] By adding an intermediate layer between the infusion station 1 and the front-end computing device 2, the intermediate layer includes driver modules DP1 to DP4 and virtual device modules VD1, VD2, and an abstraction between the infusion station 1 and the front-end computing device 2 is established. In this article, in the upstream direction A1, through the intermediate layer, the specific protocol diagram for data transmission from the infusion station 1 through the specific communication channels C1 to C4 is removed in the intermediate layer, and the data is processed and merged into the general data model M, and the processed and merged data is buffered in the associated virtual device modules VD1, VD2. Each front-end computing device 2 must only implement a single virtual device protocol or protocol set to communicate with the associated virtual device modules VD1, VD2 to access data from the infusion station 1 or send data to the infusion station 1.

[0092] This has the advantage that the implementation of the system is facilitated, since adding or modifying an infusion station 1 does not require modification of the front-end computing device 2. If a new device is added to the system, in principle only a new driver module, e.g. in the form of a dynamic link library, needs to be installed and dynamically linked to the virtual device modules VD1, VD2.

[0093] The underlying concepts of the invention are not limited to the embodiments described above, but can be implemented in completely different ways.

[0094] The infusion station may include one or more pump devices placed on a rack, which communicate, for example, via the rack. Likewise, the infusion station may be an independent pump device connected to the hospital communication network by itself.

[0095] With a setup of the type described herein, communication can be enabled between an infusion station and a front-end computing device having pump devices belonging to one or more different manufacturers, the pump devices belonging to different families and being of different types and using different communication channels defined by different protocols.

[0096] Reference numerals list

[0097] 1 Infusion station

[0098] 10 racks

[0099] 11. Medical Equipment

[0100] 12 Infusion station (medical equipment)

[0101] 2 Front-end computing equipment

[0102] 3 Server System

[0103] 4 Communication Network

[0104] A1 Upstream direction

[0105] A2 Downstream direction

[0106] C1-C4 Communication Channel

[0107] d1-d5 Extracted data

[0108] D1, D2 device types

[0109] DP1-DP4 Driver Modules

[0110] F1, F2 device families

[0111] M Data Model

[0112] M1, M10-M19 data structure

[0113] M180-M182 Data Structure

[0114] M190-M202 Data Structure

[0115] m1-m3 messages

[0116] P1-P4 Protocol

[0117] VD Virtual Device Protocol

[0118] VD1, VD2 virtual devices

[0119] U User

Claims

1. A method for data communication between an infusion station (1) and a front-end computing device (2) in a healthcare environment, the method comprising: At least one of: sending data in an upstream direction (A1) and receiving data in a downstream direction (A2) by at least one infusion station (1) for performing an infusion operation, and At least one of the following: receiving data related to the at least one infusion station (1) in the upstream direction (A1) and sending data related to the at least one infusion station (1) in the downstream direction (A2) by at least one front-end computing device (2), It is characterized in that At least one of: receiving data from the at least one infusion station (1) in the upstream direction (A1) and sending data to the at least one infusion station (1) in the downstream direction (A2) by the driver modules (DP1 to DP4), and At least one of the following: sending data to the at least one front-end computing device (2) in the upstream direction (A1) and receiving data from the at least one front-end computing device (2) in the downstream direction (A2) by the virtual device module (VD1, VD2), wherein the driver modules (DP1 to DP4) perform at least one of the following operations: processing data received from the at least one infusion station (1) in the upstream direction (A1) to provide the data to the virtual device modules (VD1, VD2), and processing data received from the virtual device modules (VD1, VD2) in the downstream direction (A2) to send the data to the at least one infusion station (1), wherein the virtual device module (VD1, VD2) comprises a data model (M) defining a plurality of data structures (M1, M10 to M19, M180 to M182, M190 to M202) in which data related to the at least one infusion station (1) are stored, wherein the driver modules (DP1 to DP4) and the virtual device modules (VD1, VD2) are hosted on a server system, and The virtual device modules (VD1, VD2) group the pump devices (11, 12) of the infusion station (1) belonging to a common device family (F1, F2).

2. The method according to claim 1, characterized in that: The at least one infusion station (1) uses a first communication protocol (P1 to P4) to communicate with the driver modules (DP1 to DP4).

3. The method according to claim 2, characterized in that Different drivers (DP1 to DP4) communicate with different infusion stations (1) using different first communication protocols (P1 to P4).

4. The method according to claim 2, characterized in that: The first communication protocols (P1 to P4) are based on HTTP, MQTT or Ethernet.

5. The method according to any one of claims 1 to 3, characterized in that The virtual device module (VD1, VD2) uses a second communication protocol (VD) to communicate with the at least one front-end computing device (2).

6. The method according to claim 5, characterized in that The second communication protocol (VD) is based on AMQP or HTTP.

7. The method according to any one of claims 1 to 3, characterized in that The virtual device modules (VD1, VD2) use an upstream protocol as a second communication protocol in the upstream direction (A1) and use a downstream protocol different from the upstream protocol as a second communication protocol in the downstream direction (A2).

8. The method according to claim 7, characterized in that The upstream protocol is based on AMQP.

9. The method according to claim 7, characterized in that: The downstream protocol is based on HTTP.

10. The method according to any one of claims 1 to 3, characterized in that The virtual device module (VD1, VD2) stores data received from the at least one infusion station (1) or from the at least one front-end computing device (2) in a predefined data structure (M1, M10 to M19, M180 to M182, M190 to M202) of the data model (M).

11. The method according to any one of claims 1 to 3, characterized in that The virtual device module (VD1, VD2) stores data related to at least one of the identity of the pump device (11, 12) of the infusion station (1), the status of the pump device (11, 12) of the infusion station (1) and the capacity of the pump device (11, 12) of the infusion station (1) in a predefined data structure (M1, M10 to M19, M180 to M182, M190 to M202) of the data model (M).

12. The method according to any one of claims 1 to 3, characterized in that The driver modules (DP1 to DP4) are implemented as dynamic link libraries or window services.

13. The method according to any one of claims 1 to 3, characterized in that Different virtual device modules (VD1, VD2) group pump devices (11, 12) belonging to different device families (F1, F2).

14. A system for data communication in a healthcare environment, the system comprising: At least one infusion station (1) for performing an infusion operation, the at least one infusion station (1) being configured to perform at least one of the following operations: sending data in an upstream direction (A1) and receiving data in a downstream direction (A2), and at least one front-end computing device (2) configured to perform at least one of the following operations: receiving data related to the at least one infusion station (1) in the upstream direction (A1) and sending data related to the at least one infusion station (1) in the downstream direction (A2), It is characterized in that A server system (3), wherein the server system hosts driver modules (DP1 to DP4) and virtual device modules (VD1, VD2), wherein the driver modules (DP1 to DP4) are configured to perform at least one of receiving data from the at least one infusion station (1) in the upstream direction (A1) and sending data to the at least one infusion station (1) in the downstream direction (A2), and the virtual device modules (VD1, VD2) are configured to perform at least one of sending data to the at least one front-end computing device (2) in the upstream direction (A1) and receiving data from the at least one front-end computing device (2) in the downstream direction (A2), wherein the driver modules (DP1 to DP4) are configured to perform at least one of sending data to the at least one front-end computing device (2) in the upstream direction (A1) and receiving data from the at least one front-end computing device (2) in the downstream direction (A2). ) to process data received from the at least one infusion station (1) to provide the data to the virtual equipment module (VD1, VD2) and to process data received from the virtual equipment module (VD1, VD2) in the downstream direction (A2) to send the data to at least one of the at least one infusion station (1), wherein the virtual equipment module (VD1, VD2) includes a data model (M) defining a plurality of data structures (M1, M10 to M19, M180 to M182, M190 to M202), in which data related to the at least one infusion station (1) are stored, and the virtual equipment module (VD1, VD2) groups the pump equipment (11, 12) of the infusion station (1) belonging to a common equipment family (F1, F2).

Images