CN114503514A - 用于医疗保健环境中的服务器系统与前端计算设备之间的数据通信的方法 - Google Patents

Abstract

在用于医疗保健环境中的服务器系统(3)与前端计算设备(2)之间的数据通信的方法中，前端计算设备(2)向服务器系统(3)的主接口(30)发送对数据连接的请求。服务器系统(3)处理该请求，并且作为处理的结果，在服务器系统(3)与前端计算设备(2)之间建立数据连接。在本文中，所述处理包括在服务器系统(3)上创建专用于该请求的次接口(32)，并且将用于访问所述次接口(32)的信息发送至前端计算设备(2)，其中，所述建立包括由前端计算设备(2)使用从服务器系统(3)接收的信息连接至所述次接口(32)。

Description

用于医疗保健环境中的服务器系统与前端计算设备之间的数 据通信的方法

本发明涉及根据权利要求1的前序部分的用于医疗保健环境中的服务器系统与前端计算设备之间的数据通信的方法，并且涉及用于医疗保健环境中的数据通信的系统。

在这种方法中，前端计算设备向服务器系统的主接口发送对数据连接的请求。服务器系统处理该请求，并且作为处理的结果，在服务器系统与前端计算设备之间建立数据连接。

在诸如医院的医疗保健环境中，通常医疗设备(例如输注站，例如以在机架上堆叠组织的泵设备或独立的泵设备的形式)连接至通信网络并且经由通信网络连接至医院信息系统。用户可以经由诸如固定个人计算机(PC)、膝上型计算机、平板计算机的前端计算设备或诸如移动电话的移动设备访问通信网络，以便接收与医疗设备相关的数据或者向医疗设备发送数据，例如用于监控正在进行的输注操作或配置泵设备例如设置输注操作。

在医院环境中，通常后端服务器形式的服务器系统用于托管向安装在前端计算设备上的前端应用提供服务的部件。在这样的服务中，通常在上游方向上从服务器系统向前端计算设备交换数据，例如以经由用户界面向用户显示前端计算设备上的数据，或者在下游方向上从前端计算设备向服务器系统交换数据，以处理数据、存储数据并且将数据传输至其他设备，例如输注站或其他服务器形式的医疗设备。

期望能够控制这样的系统内的数据交换，以使得前端计算设备能够访问与医疗设备相关的数据，特别地在上游方向上接收数据，例如用于监控输注操作，或者在下游方向上向医疗设备发送数据，例如用于对医疗设备进行编程。

WO 2014/131729 A2描述了用于向位于医疗保健环境中的医疗设备提供药物库数据的系统，该系统包括本地网络和用于向患者施用药物的至少一个医疗设备，该至少一个医疗设备位于医疗保健环境中并且连接至本地网络。本文中的药物库数据经由公共通信网络传输至该至少一个医疗设备。

本发明的目的是提供一种用于在医疗保健环境中的服务器系统与前端计算设备之间的数据通信的方法以及一种用于数据通信的系统，其允许以简单的方式在请求数据连接时提供前端计算设备与服务器系统之间的数据交换。

该目的借助于包括权利要求1的特征的方法来实现。

因此，所述处理包括在服务器系统上创建专用于该请求的次接口，并且将用于访问所述次接口的信息发送至前端计算设备，其中，所述建立包括由前端计算设备使用从服务器系统接收的信息连接至所述次接口。

前端计算设备(特别地在前端计算设备上运行的应用)可能希望访问服务器系统，例如医疗保健环境例如医院中的后端服务器。为此，前端计算设备向服务器系统发送请求，该请求首先定向至非专用主接口，运行不同应用的不同前端计算设备可以经由该非专用主接口连接至服务器系统。在接收到这样的请求时，服务器系统处理该请求，并且在处理的背景下，在服务器系统上创建专用于该请求的次接口。然后，服务器系统将信息发送至前端计算设备，这使得前端计算设备能够访问所述次接口以建立(逻辑)数据连接。

因此，借助于前端计算设备到服务器系统的第一连接经由主接口进行，前端计算设备将其初始请求定向至该主接口。根据该请求，服务器系统创建专用次接口，该专用次接口仅专用于前端计算设备和由前端计算设备发出的特定请求。在已经接收到识别前端计算设备的次接口的信息之后，前端计算设备连接至次接口，并且以这种方式建立到服务器系统的数据连接。然后，经由数据连接，可以在前端计算设备与服务器系统之间交换数据，这样的连接例如允许从服务器系统接收数据，例如以便获得一个或多个输注站的信息(例如，与在那些输注站上执行的输注操作相关的信息)，并且可能潜在地向服务器系统传输数据，以便例如向输注站发送数据，例如用于对输注站进行编程或者用于修改输注站的配置。

数据连接可能是单向连接或双向连接。在一个实施方式中，数据连接是单向的，原因在于前端计算设备可以经由次接口接收数据，但是不能向次接口发送数据。在这种情况下，从前端计算设备向服务器系统的数据传输可以经由主接口进行。因此，次接口是只读接口。在另一实施方式中，数据连接可以是双向连接，使得前端计算设备可以从次接口接收数据并且可以将向次接口发送数据。

数据连接被建立为逻辑网络连接，该逻辑网络连接由例如前端计算设备的特定应用的端口和/或IP地址以及在服务器系统上创建的次接口来限定。

也称为主API(API代表应用编程接口)的主接口用于接收来自外部前端计算设备(特别地在前端计算设备上运行的应用)的所有请求。主接口可以将请求委托给服务器系统的管理引擎，该管理引擎处理该请求并且创建也称为数据API的次接口。

当针对每个请求创建专用接口时，可以以逻辑的、系统的方式建立数据传输。在本文中，一个前端计算设备可以经由若干个次接口访问服务器系统，一个次接口与从前端计算设备(特别地在前端计算设备上运行的一个或多个应用)发出的每个请求相关联。

在一个实施方式中，如请求所指定和允许的，本文中的次接口允许数据传输。因此，经由次接口，可以仅交换在请求中限定并由请求限定和被请求允许的这样的数据。

例如，在请求中，可以限定与特定输注站的数据通信应被启用。在这种情况下，经由专用次接口创建的数据连接允许在请求实体(特别地在前端计算设备上运行的特定应用)与特定输注站之间进行数据传输，但是不允许访问与其他输注站相关的数据。

在一个实施方式中，服务器系统中正在进行的处理包括根据请求中包括的信息借助于基于请求的认证和/或授权进行的验证。因此，基于该请求，执行认证和/或授权，以检查请求实体(特别地前端计算设备的应用)是否向服务器系统注册(认证)以及是否被允许访问在请求中限定的数据(授权)。

在认证中，检查与请求实体的身份相关的信息。在一个实施方式中，认证可以采用预共享密钥(PSK认证)。这样的预共享密钥是由请求实体(特别地在前端计算设备上运行的特定应用)和服务器系统两者已知的。对于认证，在请求中，例如可以提供识别由预共享密钥编码的请求实体的信息，其中，服务器系统能够对该信息进行解码并且基于正确的解码对该请求进行认证。

在一个实施方式中，仅在认证成功的情况下，才创建次接口。如果认证不成功，则请求被拒绝，无需创建次接口。

在一个实施方式中，服务器系统可以存储关于授权前端计算设备的特定应用借助于服务器系统访问数据的信息。在本文中，对于每个注册的应用和每个注册的前端计算设备，可以限定一组特定的授权，即允许特定应用和特定前端计算设备访问的特定数据集。在授权过程中，检查请求实体(特别地前端计算设备的特定应用)是否被允许访问请求中陈述的数据，并且仅在成功授权时，请求实体才被允许访问数据。

为了允许请求的前端计算设备(特别地在前端计算设备上运行的特定应用)经由次接口建立到服务器系统的数据连接，用于访问次接口的相关信息借助于服务器系统被发送至前端计算设备。在一个实施方式中，这样的信息可以包括识别网络上的次接口的地址信息，例如次接口的端口号或IP地址。另外，可以将凭证发送至请求实体，例如专用密码等，这样的凭证使得请求实体能够访问次接口以便建立数据连接。

一旦前端计算设备已经接收到关于次接口的信息，前端计算设备就可以连接至次接口，并且因此可以建立数据连接。然后，经由数据连接，可以执行前端计算设备与服务器系统之间的数据通信，使得可以将例如与输注站相关的数据发送至服务器系统，以及/或者可以从服务器系统接收数据。

经由次接口建立的数据连接可以是持久的，原因在于它允许进行稳定的数据通信，例如以在相当长的时间跨度上监控正在进行的输注操作。数据连接可以由前端计算设备取消，或者可以在前端计算设备被允许访问的预定义时间之后自动取消，例如在具有预定长度的预定义会话的意义上。

在一个实施方式中，服务器系统包括用于向前端计算设备发送数据或从前端计算设备接收数据的数据引擎。数据引擎可以存储与输注站或其他外部服务相关的信息。经由数据引擎，可以将数据传输至针对特定次接口限定的前端计算设备，或者可以借助于前端计算设备将数据传输至服务器系统。

本文中的数据引擎可以在上游方向上将数据提供给次接口以发送至前端计算设备。在一个实施方式中，反过来，在下游方向上，数据引擎可以经由主接口从前端计算设备接收数据。因此，仅在上游方向上，数据传输经由次接口进行。

在一个实施方式中，数据引擎可以使用驱动器模块与至少一个输注站进行通信，该驱动器模块被配置成在上游方向上从至少一个输注站接收数据以及/或者在下游方向上向至少一个输注站发送数据。

特别地，驱动器模块用于提供与一个或多个输注站的通信，其中，输注站可以包括一个或多个不同类型的不同泵设备，不同泵设备采用不同的协议来传送数据。驱动器模块(特别地管理与输注站的连接)能够使用特定输注站所需的通信协议进行通信，并且因此能够处理使用与该输注站相关联的特定通信协议从输注站接收的数据以及向所述输注站发送的数据。

在另一实施方式中，数据引擎可以使用虚拟设备模块与前端计算设备进行通信，该虚拟设备模块被配置成在上游方向上向前端计算设备发送数据和在下游方向上从前端计算设备接收数据，其中，驱动器模块在上游方向上处理使用所述第一通信协议从至少一个输注站接收的数据以将所述数据提供给虚拟设备模块以及/或者在下游方向上处理从虚拟设备模块接收的数据以使用所述第一通信协议将所述数据发送至至少一个输注站。在本文中，虚拟设备模块包括限定多个数据结构的数据模型，数据结构中存储有与至少一个输注站相关的数据

因此，虚拟设备模块经由创建的专用次接口提供与前端计算设备的数据通信。虚拟设备模块包括限定多个数据结构的数据模型。在数据模型中，由驱动器模块处理的数据存储在限定的专用数据结构中，使得从一个或多个输注设备接收的数据根据数据模型的数据结构被组织在限定的结构中。在虚拟设备模块中，与一个或多个输注设备相关的数据因此被组织在独立于通信协议的结构中，借助于该通信协议在一个或多个输注设备与驱动器模块之间传送数据。

虚拟设备模块中包括的数据模型内与一个或多个输注设备相关的数据的组织允许使用公共通信协议与一个或多个前端计算设备进行通信。特别地，可以使用公共通信协议从虚拟设备模块向一个或多个前端计算设备传送数据，该公共通信协议独立于借助于其在输注设备与虚拟设备模块之间传送数据的任何通信协议。

因此，前端计算设备与虚拟设备模块之间的数据通信独立于输注设备与虚拟设备模块之间的任何数据通信(经由一个或多个驱动器模块)。借助于虚拟设备模块，提供了允许在前端计算设备与虚拟设备模块之间进行数据传输的通用数据模型。可以使用公共通信协议在虚拟设备模块与前端计算设备之间交换数据，数据通信独立于驱动器模块与相关的输注设备之间的数据通信(涉及用于数据通信的特定通信协议)。

在一个实施方式中，不同的驱动器模块可以使用不同的第一通信协议与不同的输注站进行通信。特别地，可能存在不同种类的输注站，包括例如不同类型的泵设备(例如容积式输注泵或注射式输注泵)并且属于不同的设备族(例如，Fresenius目前正在提供所谓的Agilia族中的泵设备和例如在所谓的Amika族中用于肠内喂养的其他泵设备)。另外，由例如独立的泵设备或组合在例如机架上的泵的堆叠构成的一个输注站可以使用不同的通信信道例如使用Wi-Fi的无线通信信道或使用例如以太网连接的有线通信信道进行通信。在本文中，对于任何输注站正在使用的每个协议，可以存在一个驱动器并且该驱动器可以安装在例如服务器系统上，使得驱动器模块实现在利用该协议的输注站与对应的虚拟设备模块之间的通信，使得可以在输注站与虚拟设备模块之间交换数据。

因此，可以例如存在第一驱动器模块用于利用第一通信信道例如有线通信信道例如以太网连接与输注站进行通信。这样的驱动器模块可以实现例如利用以太网协议的通信。可以存在第二驱动器模块用于利用第二通信信道例如无线通信信道与输注站进行通信，使得能够利用Wi-Fi(无线LAN)协议、蓝牙协议、NFC(近场通信)协议等进行通信。对于不同类型和例如属于不同设备族的输注站，可以存在第三驱动器模块。总体而言，可以为输注站与服务器系统之间的每个通信信道提供一个驱动器模块。

在一个实施方式中，第一通信协议可以基于WiFi、HTTP或以太网。这样的协议可以标准化。WiFi协议例如在IEEE 802.11标准中标准化。以太网协议在IEEE 802.3标准中标准化。另外，基于标准化协议，可以采用由泵制造商实现的专有修改，使得特定输注站使用的协议除了标准化协议方案之外还可以采用专有方案。

用于在虚拟设备模块与前端计算设备之间进行通信的第二通信协议可以不同于第一通信协议，或者可以相同。例如，第二通信协议可以基于AMQP或HTTP。在本文中，公共通信协议可以用于前端计算设备与一个或多个虚拟设备模块之间的通信，公共第二通信协议独立于用于在输注设备与相关联的驱动器模块之间进行通信的任何通信协议。

尽管针对不同的输注站存在不同的驱动器模块，并且不同的驱动器模块使用不同的通信协议用于与不同的输注站进行通信，但是虚拟设备模块与不同的前端计算设备之间经由不同的专用次接口的通信使用公共协议方案进行，使得所有前端计算设备利用相同的通信协议或通信协议集与虚拟设备模块进行通信。

在一个实施方式中，虚拟设备模块在上游方向上使用上游协议作为第二通信协议，以及在下游方向上使用不同于上游协议的下游协议作为第二通信协议。因此，根据通信在上游方向上进行还是在下游方向上进行而采用不同的协议。

上游协议可以例如基于AMQP，而下游协议可以例如基于HTTP。

在一个实施方式中，在上游方向上和下游方向上不同协议的使用是基于虚拟设备模块应利用由数据模型限定的数据结构将从一个或多个输注站或从一个或多个前端通信设备接收的数据缓冲在数据模型中。特别地，虚拟设备模块可以将与输注站的泵设备的身份、输注站的泵设备的状态以及输注站的泵设备的能力相关的数据存储在相关联的预定义的数据结构中。因此，虚拟设备模块合并与泵设备相关的数据，并且以有组织的方式将数据存储在结构化的通用数据模型中，使得前端计算设备可以经由专用次接口从虚拟设备模块接收数据，以获得与特定泵设备或包括多个泵设备的特定输注站相关的信息。

在本文中，在一个实施方式中，数据模型的结构独立于虚拟设备模块，不同的虚拟设备模块使用具有相同结构的同一通用数据模型。

在数据模型中，可以使用例如XML(扩展标记语言)来存储数据。

为了在驱动器模块与相关联的虚拟设备模块之间传送数据，可以采用允许数据缓冲的协议，特别地AMQP(AMQP代表高级消息队列协议)，AMQP是面向消息的中间件的开放标准应用层协议并且允许数据消息排队。

特别地，虚拟设备模块可以存储与泵设备的身份相关的信息，例如泵设备的族、泵设备的类型以及当前安装在泵设备上的硬件或软件的版本。

另外或替选地，虚拟设备模块可以存储与泵状态相关的信息，例如泵设备的连接性、正在进行的输注操作的输注状态、泵设备在机架上的位置以及泵设备在医疗保健环境例如医院中的位置。与输注状态相关的信息可以包括输注操作的药物、剂量、剂量率、输注时间、输注剩余时间、患者信息等。

另外或替选地，虚拟设备模块可以存储与泵设备的能力相关的信息，其中，能力可以取决于通信信道，泵设备借助于该通信信道连接至通信网络并且因此能够与对应的驱动器模块通信。特别地，能力可以包括取决于连接泵设备的通信信道可用的临床功能。例如，如果泵设备借助于无线通信信道连接，则与其他通信信道例如有线通信信道相比，可能只有一部分临床功能可用。这样的临床功能可以例如涉及自动编程、自动文档、药物库配置、技术配置、固件上传以及与泵设备相关的设备事件日志。例如，固件上传可能仅对于有线通信信道可用，但如果泵设备经由无线通信信道连接则不可用。

对于本文中的预定义种类的信息，预定义的数据结构可以存在于包括在虚拟设备模块中的数据模型中，使得与输注设备相关的信息存储在预定义的数据结构中，独立于用于在输注设备与相关驱动器模块之间传送数据的任何通信协议。

在一个实施方式中，每个驱动器模块被实现为动态链接库(简称：dll)或窗口服务。动态链接库表示可以被软件应用采用的共享库。这样的动态链接库允许以模块化的方式提供可以由不同应用共同执行的可执行编程代码。具有以.dll结尾的文件的动态链接库特别地在窗口操作系统环境中被采用。

在一个实施方式中，虚拟设备模块将属于公共设备族的输注站的输注设备分组。在本文中，可以针对每个设备族安装一个虚拟设备模块，使得每个族存在一个虚拟设备模块。在虚拟设备模块中，与属于同一族但可能属于不同类型的泵设备(例如容积式输注泵和注射式输注泵)相关的信息可以由前端计算设备存储和访问。

对于驱动器模块与对应的虚拟设备模块之间的数据通信，可以采用诸如AMQP的公共协议，其中，每个驱动器模块利用相同的协议与对应的虚拟设备模块进行通信。本文中的一个虚拟设备模块可以与不同的驱动器模块——即针对设备族的泵设备正在使用的每个协议的一个驱动器模块——进行通信。

该目的还借助于一种用于医疗保健环境中的数据通信的系统来实现，该系统包括：服务器系统，其包括主接口；以及前端计算设备，其被配置成向服务器系统的主接口发送对数据连接的请求，其中，服务器系统被配置成处理所述请求，以便作为处理的结果，使得能够在服务器系统与前端计算设备之间建立数据连接。在本文中，服务器系统被配置成在处理期间在服务器系统上创建专用于该请求的次接口，并且将用于访问所述次接口的信息发送至前端计算设备，其中，前端计算设备配置成使用从服务器系统接收的信息连接至所述次接口。

上述针对该方法的优点和有利实施方式同样也适用于该系统，因此在这方面应参考上文。

随后将参照附图中所示的实施方式更详细地描述本发明隐含的构思。在本文中：

图1示出了用于医疗保健环境中的数据通信系统的示意图；

图2示出了前端计算设备到服务器系统的连接的示意图；

图3示出了用于在前端计算设备与服务器系统之间建立数据连接的服务器系统的设置的示意图；以及

图4示出了采用中间层在输注站与前端计算设备之间的通信，该中间层包括驱动器模块和虚拟设备模块，用于转换和抽象输注站与前端计算设备之间的数据通信；

图5示出了包括用于以有组织的方式在虚拟设备模块中存储数据的数据结构的数据模型的示意图；

图6示出了包括子结构的数据结构的示意图；

图7示出了用于采用数据引擎在前端计算设备与服务器系统之间建立数据连接的服务器系统的设置的示意图，该数据引擎包括驱动器模块和虚拟设备模块，用于转换和抽象输注站与前端计算设备之间的数据通信；

图8示出了下游数据通信的示意图；以及

图9示出了上游数据通信的示意图。

图1以示意图示出了如在医疗保健环境例如医院中可以找到的布置。

也就是说，在医疗保健环境中，输注站1诸如以有组织的方式放置在机架10上的泵设备11的堆叠或独立的泵设备12可以连接至医院通信网络4并且经由通信网络4连接至医院信息系统(HIS)。另外，诸如固定个人计算机(PC)、膝上型计算机、平板计算机或移动通信设备(例如移动电话)的前端计算设备2连接至通信网络4。服务器系统3特别地包括一个或多个(分布式的)物理服务器实体的后端服务器连接至通信网络4，通信网络4使得能够在输注站1、前端计算设备2与服务器系统3之间进行数据通信。例如在整个医疗保健环境中将药物库数据分发至医疗设备的背景下，附加服务器5可以连接至通信网络4，这样的服务器5存储例如数据或者服务于特定的临床功能。

在医疗保健环境的背景下，用户可能希望将输注操作设置成由一个或多个泵设备11、12执行，在不同病房和不同房间的整个医疗保健环境中，这样的泵设备11、12被布置在不同患者的床边处。为此，用户可能希望将编程数据传输至一个或多个泵设备11、12以便设置输注操作，或者例如通过将药物库数据传输至一个或多个泵设备11、12来管理和执行一个或多个泵设备11、12的配置，这样的药物库数据提供用于设置输注操作的一般边界和指南，例如特定药物的剂量率的边界等。

另外，用户可能希望监控由一个或多个泵设备11、12执行的正在进行的输注操作，这需要从泵设备11、12向前端计算设备2的数据传输，用户可以经由该前端计算设备2访问数据。

现在参照图2，在医疗保健环境中，数据通信可以经由服务器系统3特别地所谓的后端服务器进行，该后端服务器提供前端计算设备2与医疗设备例如输注站1以及托管特定服务的数据或应用的其他服务器5之间的数据通信。本文中的前端计算设备2可以在上游方向A1(从服务器系统3向前端计算设备2)和下游方向A2(从前端计算设备2向服务器系统3)上与服务器系统3进行通信。诸如固定PC、膝上型计算机、平板计算机或移动设备(例如移动电话)的前端计算设备2可以例如经由诸如显示器的用户界面向用户U提供数据。

现在参照图3，为了访问服务器系统3，前端计算设备2可以发出请求，并且可以将请求发送至服务器系统3的主接口30，该主接口30例如由端口号和IP地址等限定，并且为不同的前端计算设备2提供通用数据接口，以连接至服务器系统3(图3中的动作B1)。借助于该请求，前端计算设备2的特定应用可以请求访问特定的数据集，例如与特定输注站1、输注站1的特定族、位于特定位置的一组医疗设备、托管在服务器5例如药物库服务器上的特定数据集等相关的数据。

在接收到请求时，服务器系统3内的请求被转发至管理引擎31，管理引擎31处理该请求(图3中的动作B2)。在处理中，可以例如通过执行认证和授权来验证请求。

在该请求内，可以提供例如与请求实体(特别地在特定前端计算设备2上运行的特定应用)的标识相关的数据，例如由对于服务器系统3特别地管理引擎31也是已知的预共享密钥(PSK)编码的ID。为了执行认证，可以借助于对于管理引擎31也已知的预共享密钥来处理这样的数据，并且借助于该处理来认证该请求，即验证该请求确实来自特定标识的实体，并且该实体被允许请求对服务器系统3的访问。

另外，在管理引擎31中，可以存储限定针对特定请求实体(例如特定前端计算设备2的特定应用)的特定授权的数据，这样的授权信息限定特定实体可以被允许访问什么数据。在授权过程中，特别地检查请求实体是否被授权访问它请求访问的数据。

如果认证和授权成功，则创建次接口32(图3中的动作B3)。次接口32专用于特定请求，并且应仅为该特定请求提供数据通信。次接口32由相关网络地址信息例如端口号和/或IP地址标识。另外，可以针对次接口32限定凭证，仅在设置连接时提供正确凭据的情况下，实体才被允许访问次接口32。

一旦创建了次接口32，与次接口32相关的信息被转发至前端计算设备2(动作B4)，特别地请求实体，即在前端计算设备2上运行的特定应用。该信息特别地包括诸如端口号和/或IP地址的地址信息，以及允许访问次接口32的凭证。

一旦接收到信息，前端计算设备2可以通过利用该信息特别地从服务器系统3接收的地址信息和凭证来连接至次接口32(图3中的动作B5)。因此，在前端计算设备2与服务器系统3之间建立数据连接，其中经由次接口32，服务器系统3的数据引擎33能够与前端计算设备2进行通信。

遵循该概念，针对特定请求动态地创建次接口32，每个次接口32与特定请求相关联并且仅允许仅针对该特定请求进行数据通信。

在本文中，使用多个不同应用的多个前端计算设备2可以向服务器系统3发出不同的请求，其中对于每个请求，创建仅用于满足相关联的特定请求的专用次接口32。

现在参照图4，输注站1(如图1中示意性地指示的，包括放置在机架10上的多个泵设备11或独立的泵设备12)可以经由通信信道C1至C4与服务器系统3的数据引擎33进行通信，每个通信信道C1至C4例如使用专用协议P1至P4用于在上游方向A1上发送数据和在下游方向A2上接收数据。

本文中的第一通信信道C1可以是例如根据Wi-Fi协议并且另外使用用于数据传输的HTTP协议的无线信道，用于将具有第一类型D1和第一族F1的泵设备的输注站1连接至前端计算设备2。替选地或另外，本文中的同一输注站1可以使用第二通信信道C2，第二通信信道2例如是有线信道，例如遵循以太网协议的以太网信道。

具有不同类型D2但属于同一族F1的泵设备的输注站1可以使用例如也是有线信道的第三通信信道C3，但是使用不同的协议P3。

具有类型D1但属于不同族F2的泵设备的另一输注站1可以使用通信信道C4，同样使用不同的协议P4用于与前端计算设备2进行通信。

本文中的泵类型D1、D2可以指示泵设备是容积式(蠕动式)输注泵还是注射式输注泵或其他类型的泵。

设备族F1、F2可以由某个制造商的品牌限定，相同族F1、F2的设备通常使用类似的基础架构，例如类似的操作软件。

通常，根据用于传输数据的信道C1至C4，数据消息m1至m3根据特定协议P1至P4的规范进行传输，协议P1至P4用于根据协议的限定对数据消息m1至m3进行打包。

为了实现输注站1与前端计算设备2之间的数据通信(一旦建立了经由专用次接口32的数据连接)，服务器系统3的数据引擎33提供了输注站1与前端计算设备2之间的转换和抽象。输注站1和前端计算设备2两者都应与数据引擎33进行通信，使得前端计算设备2不一定必须能够根据特定输注站1针对特定通信信道C1至C4所使用的协议P1至P4进行通信。

数据引擎33实现驱动器模块DP1至DP4，驱动器模块DP1至DP4用于提供与输注站1的通信。另外，安装了虚拟设备模块VD1、VD2，虚拟设备模块VD1、VD2被配置成提供与前端计算设备2的数据通信。

驱动器模块DP1至DP4可以例如通过所谓的动态链接库(.dll文件)实现，其例如在Microsoft Windows操作系统环境中提供可以由不同软件应用采用的可执行软件代码的动态可链接库。本文中使用特定协议P1至P4的每个通信信道C1至C4与特定驱动器模块DP1至DP4相关联，每个驱动器模块DP1至DP4能够提供使用特定协议P1至P4的通信。

也就是说，在图4的示例中，存在与第一驱动器模块DP1相关联的使用第一协议P1的第一信道C1，该第一信道C1例如用于无线数据通信。第二通信信道C2例如使用第二协议P2的有线信道例如根据以太网协议的以太网信道与第二驱动器模块DP2相关联。使用第三协议P3的第三通信信道C3与第三驱动器模块DP3相关联。使用第四协议P4的第四通信信道C4与第四驱动器模块DP4相关联。

每个驱动器模块DP1至DP4被配置成经由特定的相关联的通信信道C1至C4提供与输注站1的数据通信，驱动器模块DP1至DP4管理连接并且被配置成处理用于在上游方向A1上以及在下游方向A2上进行通信的数据。

也就是说，在上游方向A1上，通过移除用于传输消息m1至m3的协议框架对经由相关联的通信信道C1至C4接收的数据进行解包。然后将这样的解包的消息m1至m3转发至相关联的虚拟设备模块VD1、VD2，如图4所示。在虚拟设备模块VD1、VD2中，如随后将更详细地说明的，从驱动器模块DP1至DP4接收的数据存储在定义的数据模型M(参见图5)中，其中数据被组织在数据结构M1、M10至M19中。

反过来，在下游方向A2上，每个驱动器模块DP1至DP4被配置成处理从相关联的虚拟设备模块VD1、VD2接收的数据消息m1至m3，以使用相关联的协议P1至P4的限定协议框架对数据消息m1至m3进行打包，使得数据消息m1至m3使用该特定协议P1至P4被转发至输注站1。

对于驱动器模块DP1至DP4与虚拟设备模块VD1、VD2之间的通信，可以采用公共协议，例如允许数据消息排队(缓冲)的协议，例如AMQP。

通常，例如在输注操作的背景下，用于在上游方向A1上从输注站1向相关联的驱动器模块DP1至DP4和虚拟设备模块VD1、VD2传输的数据可以以同步的方式进行，数据传输例如在数据事件发生时以事件-触发的方式进行。本文中包括驱动器模块DP1至DP4和虚拟设备模块VD1、VD2的数据引擎33被配置成缓冲和存储从输注站1接收的数据，使得当所存储的数据被用户U请求时，所存储的数据可以被转发至前端计算设备2。

虚拟设备模块VD1、VD2用于与前端计算设备2进行通信。在本文中，对于每个设备族F1、F2，可以在包括针对设备族F1、F2的数据模型的数据引擎33中实现一个虚拟设备模块VD1、VD2。在图4的示例中，第一设备族F1与虚拟设备模块VD1相关联。第二设备族F2与虚拟设备模块VD2相关联。

虚拟设备模块VD1、VD2特别地用于存储和合并与输注站1和这样的输注站1的泵设备相关的信息。

特别地，在虚拟设备模块VD1、VD2中，可以存储与相关联的设备族F1、F2的泵的身份相关的信息，这样的信息包括关于设备族F1、F2、泵类型D1、D2以及泵设备的版本例如硬件版本或所安装的软件版本的信息。

替选地或另外，虚拟设备模块VD1、VD2可以存储与泵状态相关的信息，例如连接状态、输注状态、泵设备11在机架10上的位置、泵设备11、12在医疗保健环境例如医院中的位置等。连接状态可以包括泵设备当前是否连接至通信网络4，并且如果泵设备当前连接至通信网络4，所述连接是经由哪个信道C1至C4进行的。输注状态可以包括输注操作当前是否正在进行，并且如果输注操作正在进行，哪些参数用于输注，例如当前输注的药物、剂量率、总剂量、输注时间和输注剩余的时间。

替选地或另外，虚拟设备模块VD1、VD2可以存储与泵能力相关的信息，其中，能力对于不同的通信信道C1至C4可以是不同的，特定输注站1借助于通信信道C1至C4连接至通信网络4，并且因此连接至服务器系统3。例如，对于无线通信信道C1，可以存在与有线信道C2至C4不同的能力。这样的能力可以涉及临床功能及其可用性，这样的临床功能包括例如自动编程功能、自动文档功能、药物库配置功能、泵设备的技术配置功能、固件上传功能以及设备事件日志功能。例如，固件上传可能仅在输注站经由有线通信信道C2至C4连接而不是经由无线通信信道C1连接时才是可能的。

现在参照图5，每个虚拟设备模块VD1、VD2包括数据模型M，在数据模型M中，与属于与虚拟设备模块VD1、VD2相关联的设备族F1、F2的输注站1相关的数据存储在预定义的、特定的专用数据结构M1、M10至M19中。

在本文中，在与设备族F1、F2相关联的每个输注站1的数据模型M中，存在包括子结构树的数据结构M1。在数据结构M1中，与特定输注设备相关的信息存储在专用结构要素中。

特别地，在第一数据结构M10中，可以存储与虚拟设备模块VD1、VD2相关的信息，输注站1与该虚拟设备模块VD1、VD2相关联。

在第二数据结构M11中，可以存储与输注站1相关的位置信息，例如识别输注站1的确切物理位置的信息，例如与医院、病房、房间以及患者的特定床相关的信息。

在第三数据结构M12中，可以存储与输注站1相关的信息，例如与泵类型、泵族、泵模型等相关的信息。

在第四数据结构M13中，可以存储与设备状态相关的信息，该信息例如与操作模式的状态(例如“关闭”、“待机”、“启动”、“开启”、“错误”、“维护”)、输注操作的状态(例如“编程正在进行”、“安装正在进行”、“正在输注”、“停止”、“暂停”、“延迟输注”)相关，可以存储与电池状态相关的信息。

在第五数据结构M14中，可以存储与警报相关的信息，例如警报和预警报。

在第六数据结构M15中，可以存储与特定输注相关的信息。在本文中，在数据子结构M16中，可以存储与新处方相关的信息，以及在数据子结构M17中，可以存储与当前处方相关的信息。在本文中，在与数据结构M17相关的子结构M18中，全局输注信息和当前输注信息可以存储在数据结构M18、M19中。在本文中，与全局输注信息相关的数据结构M18可以与结构要素M180至M182相关联，在结构要素M180至M182中，可以存储与患者相关的信息(例如患者的姓名、体重、身高、性别和年龄)、与药物相关的信息(例如药物浓度和稀释度)以及与护理区域(例如重症监护室)相关的信息。

在子结构M19(与识别与当前处方相关的信息的数据结构M17相关联)中，可以存储与当前输注操作相关的信息，如图6中的说明性示例所示。

特别地，在数据结构M19中，可以存储与当前正在进行的输注操作相关的所有信息，例如与编程模式相关的信息(数据结构M190，例如“时间速率”、“量速率”、“量时间”、“量时间速率”、“TCI”、“斜坡”、“顺序”)、与递送模式相关的信息(数据结构M191，例如“标准”、“手动推注”、“编程推注”、“简单推注”、“灌注”)、与流速相关的信息(数据结构M192)、与剂量率相关的信息(数据结构M193)、与处方量相关的信息(数据结构M194)、与剩余量相关的信息(数据结构M195)、与输注量相关的信息(数据结构M196)、与输注剂量相关的信息(数据结构M197)、与递送失败的原因相关的信息(数据结构M198)、与剂量完成状态相关的信息(数据结构M199)、与输注操作的剩余持续时间相关的信息(数据结构M200)、与在顺序输注操作的背景下直至从中抽取药物的容器结束的时间相关的信息(数据结构M201)以及与剩余暂停时间相关的信息(数据结构M202)。

因此，在数据模型M中，限定的信息片段存储在限定的数据结构中。信息是从由输注站接收的通信消息中提取的，通信消息的处理由驱动器模块DP1至DP4进行，驱动器模块DP1至DP4将数据转发至虚拟设备模块VD1、VD2以存储在通用数据模型M中。前端计算设备2然后可以与数据模型M交换数据，使得信息可以被提供给前端计算设备2，并且反之亦然，由前端计算设备2发布的信息可以存储在数据模型M中并且传输至相关的输注站1。

现在再次参照图4，虚拟设备模块VD1、VD2使用公共协议或协议集与前端计算设备2进行通信，其中这样的协议或协议集不受用于与输注站1进行通信的协议P1至P4的影响。

在本文中，对于虚拟设备模块VD1、VD2与前端计算设备2之间的通信，在上游方向A1和下游方向A2上可以使用不同的协议。在上游方向A1上，例如可以使用排队协议，例如AMQP。反过来，在下游方向上，可以采用HTTP协议，例如另外采用XML和/或JSON。

在本文中，通常，每个虚拟设备模块VD1，VD2将从由输注站1接收的消息m1至m3中提取的数据d1至d5(其中每个输注站1可以发送包含不同数据的不同消息)存储在例如包含纯数据d1至d5的通用数据模型中。根据特定请求，根据限定的协议VD(由图4中的数据传输VD(d1、d2、d3、d4、d5)示出)经由针对该请求专门创建的专用次接口32将这样的数据提供给前端计算设备2。

与从输注站1向虚拟设备模块VD1、VD2的数据传输类似，例如在用户U输入例如用于对输注站1进行编程并且设置输注操作的信息的情况下，从计算设备2向虚拟设备模块VD1、VD2的数据传输可以以同步的、事件驱动的方式进行。虚拟设备模块VD1、VD2将这样的信息存储在数据模型M中，使得例如一旦通信成为可能，例如一旦输注站1借助于特定通信信道C1至C4连接至通信网络4，信息就以缓冲的方式传输至一个或多个输注站1。

现在参照图7，如上所述，在一个实施方式中，数据引擎33实现一个或多个虚拟设备模块VD1和一个或多个驱动器模块D1、D2用于经由不同的通信信道与输注站1进行通信。经由数据引擎33，特别地经由在数据引擎33上实现的虚拟设备VD1，向前端计算设备2提供数据并且从前端计算设备2接收数据。

如图7所示，次接口32(数据API)可以包括逻辑处理器320，数据从数据引擎33发送至该逻辑处理器320，以经由专用次接口32向前端计算设备2发送。逻辑处理器320负责处理一个或多个前端计算设备2的请求，并且使用排队和过滤技术创建用于与一个或多个前端计算设备2通信的数据流。

现在参照图8和图9，在下游方向A2(图8)上从前端计算设备2的数据通信和在上游方向A1(图9)上向前端计算设备2的数据通信可以不同地进行。

特别地，如图8所示，通过经由主接口30访问服务器系统3，可以经由路线R1进行下游方向A2上的通信。因此，前端计算设备2经由主接口30和管理引擎31向与特定输注站1相关联的虚拟设备VD1发送数据，例如针对输注装置1的控制数据，例如药物库数据。虚拟设备1托管在数据引擎33上，数据存储在包括在虚拟设备模块VD1中的数据模型M中。然后可以经由驱动器模块D1、D2和相关联的通信路径以异步方式向输注站1推送数据，例如向输注站1推送数据取决于它们在虚拟设备模型VD1的数据模块M中的可用性。

相反，在上游方向A1上，如图9所示，使用路线R2经由专用次接口32向前端计算设备2发送数据。因此，在上游方向A1上，向前端计算设备2的数据通信经由次接口32进行，次接口32例如可以是只读的，使得前端计算设备2可以从次接口32接收数据，但是不能向次接口发送数据。对于数据传输，虚拟设备模块VD1向次接口32转发数据，其中在设置数据连接的背景下，根据前端计算设备2的初始请求，借助于逻辑处理器320将数据包括在对应的数据流中。

可以使得虚拟设备VD1能够管理用于在前端计算设备2与输注站1之间进行数据通信的数据。特别地，在下游方向A2或上游方向A1上的数据传输可以取决于特定通信信道，特定数据传输仅可能经由特定的专用通信通道进行。

例如，可能的情况是，药物库数据可以仅经由无线通信信道在下游方向A2上从前端计算设备2向输注站1发送，输注站1借助于该无线通信信道(直接或间接)连接至服务器系统3。可以使得虚拟设备模块VD1能够检测与特定输注站1的无线通信信道是否可用，并且如果无线通信信道可用，则其向输注站1推送药物库数据。

在另一示例中，涉及输注站1在上游方向A1上的数据传输的监控可能仅经由有线通信信道例如输注站1与服务器系统之间的以太网连接是可能的。同样，使得虚拟设备模块VD1能够检测到输注站1的有线连接是否可用，并且如果有线连接可用，则监控被启用并且数据向前端计算设备2发送以启用监控。

本发明隐含的构思不限于上述实施方式，而是可以以完全不同的方式被实现。

借助于如本文所述的概念，医疗保健环境中的前端计算设备(特别地在前端计算设备上运行的应用)与服务器系统之间的数据通信以逻辑组织的方式成为可能。这样的通信可以使用共享密钥以加密方式进行，该共享密钥在设置数据连接时也用于认证。

本文中的数据通信可以涉及与输注站例如以堆叠方式布置的泵设备或独立的泵相关的数据。这样的数据还可以涉及医疗保健环境中的其他信息，例如患者特定信息。

附图标记列表

1 输注站

10 机架

11 医疗设备

12 输注站(医疗设备)

2 前端计算设备

3 服务器系统

30 主接口

31 管理引擎

32 次接口

320 逻辑处理器

33 数据引擎

4 通信网络

5 服务器设备

A1 上游方向

A2 下游方向

B1-B5 动作

C1-C4 通信通道

D1至D5 提取的数据

D1，D2 设备类型

DP1-DP4 驱动器模块

F1，F2 设备族

M1-M3 消息

P1-P4 协议

R1，R2 路线

VD 虚拟设备协议

VD1，VD2 虚拟设备

U 用户

Claims (15)

1.一种用于医疗保健环境中的服务器系统(3)与前端计算设备(2)之间的数据通信的方法，所述方法包括：

由所述前端计算设备(2)向所述服务器系统(3)的主接口(30)发送对数据连接的请求，

由所述服务器系统(3)处理所述请求，以及

作为所述处理的结果，在所述服务器系统(3)与所述前端计算设备(2)之间建立数据连接，

其特征在于，

所述处理包括在所述服务器系统(3)上创建专用于所述请求的次接口(32)，并且将用于访问所述次接口(32)的信息发送至所述前端计算设备(2)，其中，所述建立包括由所述前端计算设备(2)使用从所述服务器系统(3)接收的信息连接至所述次接口(32)。

2.根据权利要求1所述的方法，其特征在于，所述处理包括根据所述请求中包括的信息来验证基于所述请求的认证和授权中至少之一。

3.根据权利要求2所述的方法，其特征在于，认证采用预共享密钥。

4.根据权利要求2或3所述的方法，其特征在于，所述服务器系统(3)存储关于授权所述前端计算设备(2)的应用借助于所述服务器系统(3)访问数据的信息。

5.根据前述权利要求中一项所述的方法，其特征在于，由所述服务器系统(3)发送至所述前端计算设备(2)的用于访问所述次接口(32)的信息包括端口号、凭证信息和IP地址中至少之一。

6.根据前述权利要求中一项所述的方法，其特征在于，所述服务器系统(3)包括用于向所述前端计算设备(2)发送数据或从所述前端计算设备(2)接收数据的数据引擎(33)。

7.根据权利要求6所述的方法，其特征在于，所述数据引擎(33)与至少一个输注站(1)进行数据连接。

8.根据权利要求7所述的方法，其特征在于，所述数据引擎(33)使用驱动器模块(DP1至DP4)与所述至少一个输注站(1)进行通信，所述驱动器模块(DP1至DP4)被配置成在上游方向(A1)上从所述至少一个输注站(1)接收数据以及/或者在下游方向(A2)上向所述至少一个输注站(1)发送数据。

9.根据权利要求8所述的方法，其特征在于，所述至少一个输注站(1)使用第一通信协议(P1至P4)用于与所述驱动器模块(DP1至DP4)进行通信。

10.根据权利要求8或9所述的方法，其特征在于，所述数据引擎(33)使用虚拟设备模块(VD1，VD2)与所述前端计算设备(2)进行通信(32)，所述虚拟设备模块(VD1，VD2)被配置成在所述上游方向(A1)上向所述前端计算设备(2)发送数据以及在所述下游方向(A2)上从所述前端计算设备(2)接收数据，其中，所述驱动器模块(DP1至DP4)在所述上游方向(A1)上处理使用所述第一通信协议(P1至P4)从所述至少一个输注站(1)接收的数据以将所述数据提供给所述虚拟设备模块(VD1，VD2)以及/或者在所述下游方向(A2)上处理从所述虚拟设备模块(VD1，VD2)接收的数据以将所述数据发送至所述至少一个输注站(1)，其中，所述虚拟设备模块(VD1，VD2)包括定义多个数据结构(M1，M10至M19，M180至M182，M190至M202)的数据模型(M)，在所述多个数据结构(M1，M10至M19，M180至M182，M190至M202)中存储有与所述至少一个输注站(1)相关的数据。

11.根据权利要求10中一项所述的方法，其特征在于，所述虚拟设备模块(VD1，VD2)使用第二通信协议(VD)用于与所述至少一个前端计算设备(2)进行通信。

12.根据权利要求11所述的方法，其特征在于，所述虚拟设备模块(VD1，VD2)在所述上游方向(A1)上使用上游协议作为所述第二通信协议(VD)，以及在所述下游方向(A2)上使用不同于所述上游协议的下游协议作为所述第二通信协议(VD)。

13.根据权利要求10至12中一项所述的方法，其特征在于，所述虚拟设备模块(VD1，VD2)将从所述至少一个输注站(1)或从所述至少一个前端计算设备(2)接收的数据存储在所述数据模型(M)的预定义的数据结构(M1，M10至M19，M180至M182，M190至M182，M190至M202)中。

14.根据权利要求10至13中一项所述的方法，其特征在于，所述虚拟设备模块(VD1，VD2)将与输注站(1)的泵设备(10，12)的身份、输注站(1)的泵设备(10，12)的状态和输注站(1)的泵设备(10，12)的能力中至少之一相关的数据存储在所述数据模型(M)的预定义的数据结构(M1，M10至M19，M180至M182，M190至M202)中。

15.一种用于医疗保健环境中的数据通信的系统，包括：

服务器系统(3)，其包括主接口(30)，以及

前端计算设备(2)，其被配置成向所述服务器系统(3)的所述主接口(30)发送对数据连接的请求，其中，所述服务器系统(3)被配置成处理所述请求，以便作为所述处理的结果，使得能够在所述服务器系统(3)与所述前端计算设备(2)之间建立数据连接，

其特征在于，

所述服务器系统(3)被配置成在所述处理期间在所述服务器系统(3)上创建专用于所述请求的次接口(32)，并且将用于访问所述次接口(32)的信息发送至所述前端计算设备(2)，其中，所述前端计算设备(2)被配置成使用从所述服务器系统(3)接收的信息连接至所述次接口(32)。

Images