Medical safety system for maintaining or configuring a medical device, and safety method

Abstract

The invention relates to a medical safety system (1) for maintaining or configuring a medical device (2), said medical safety system comprising: the medical device (2); a decentralised acquisition device (4) having a screen; and a central data-processing unit (6); wherein the medical safety system (1) is designed to establish a two-stage data connection comprising: a first digital data connection between the decentralised acquisition device (4) and the medical device (2), which connection is a secure data connection; and a second digital data connection between the central data-processing unit (6) and the decentralised acquisition device (4), which connection is a network data connection. The invention also relates to a medical safety method.

Description

[0001] Medical safety system for maintenance or configuration of a medical device and safety procedures

[0002] Description

[0003] Technical area

[0004] The present disclosure relates to a medical security system for maintaining or configuring a medical device, comprising: (at least) the medical device, in particular a blood treatment machine and / or a medical robot with an internal control unit (in particular a plurality of different medical devices), a decentralized acquisition device, in particular an edge device such as a tablet or a smartphone, with a screen, which is provided on-site in a medical facility with the medical device; and a central data processing unit, in particular a cloud server. Furthermore, the present disclosure relates to a medical security system.

[0005] Technical background of the revelation

[0006] Modern medical devices are often connected to so-called cloud systems. Large files or large volumes of data, such as software installation files or log files, can be transferred between individual medical devices and the (central) cloud system or cloud server. The medical device itself then automatically reports the success or failure of the file download or software installation after completion.

[0007] However, there are various situations where it is not possible to connect the medical device (data-wise) to the central cloud server, or where there is no access to central systems in the cloud. Therefore, an additional option or method is required to exchange even large files between these unconnected medical devices and the cloud efficiently and without exchanging results between the devices.

[0008] For example, in the case of technical service, it may be necessary to evaluate the medical device's log files. These log files are collected on a portable USB stick via device export. However, there is no guarantee that such files will not be exchanged between devices (the log files do not necessarily contain sufficient information for device identification).

[0009] Furthermore, uploading this data is a manual and therefore inefficient task, where devices can be accidentally replaced, or the technician can forget to upload the data, or old data may still be present on the USB stick and the log files may be replaced.

[0010] In particular, possible software installation files and the installation itself are usually transferred or performed via portable USB sticks. The USB stick contains an executable installation file or a file that is executed on the device after downloading. The USB stick must be inserted into the USB port of the medical device. The data or files to be transferred can be, for example, a software installation file for updating or upgrading the medical device and / or a log file of the medical device or an installation log file of an installation process.

[0011] The following disadvantages in particular can occur with the familiar digital data connection between the medical device and the data processing unit. Firstly, there may be cases in which a digital data connection cannot be established. This can happen in particular when the medical devices are located in shielded rooms, such as basements, and therefore have no internet connection. In some applications, a wireless data connection is not possible because the electromagnetic signals of the data connection would interfere with other electromagnetic signals, resulting in unwanted overlap. Some medical devices also do not have an interface for a data connection, whether for security or cost reasons. Data transfers via USB stick can always carry the risk of unwanted or malicious software being transferred to the medical devices.

[0012] After an action has been (manually) performed on the medical device, such as updating the software or activating the license, this information must be manually stored or entered by a user in the central data processing unit. However, this entry is not reliable, as the documentation is often forgotten by the user. As a result, the

[0013] Traceability of the documentation is no longer given because the setting (or the information about the software version or the license) on the medical device does not match the setting stored in the data processing unit.

[0014] In summary, the current state of the art leads to the following problems in particular:

[0015] - Low level of security, in particular the installation can be carried out incorrectly by inexperienced users,

[0016] - The use of uncontrolled USB sticks poses a threat to the cybersecurity of the medical device,

[0017] - Installation and protocol data can be accidentally exchanged between devices, especially if old data is still present on the USB stick or old software installations are applied to the medical device or medical device,

[0018] - the result / outcome of the installation performed is missing for continuous documentation because the user forgets to add this information manually.

[0019] From a regulatory perspective, it is also necessary to know which software version is installed on a specific medical device (traceability for product recalls and documentation purposes). From a customer service perspective, it is also necessary to know the current software version of a medical device or have access to recorded log files in order to provide better and more efficient customer service. Therefore, device-specific documentation is very important and must be maintained consistently.

[0020] Summary of Revelation

[0021] It is therefore the object of the present disclosure to overcome or at least mitigate the disadvantages of the prior art and, in particular, to provide a medical safety system and a safety method that enable the highest possible operational reliability of a medical device. One sub-objective can be seen, in particular, in ensuring continuous documentation.

[0022] These objects of the present disclosure are achieved according to the invention with regard to a medical security system by the features of claim 1, and with regard to a medical security method by the features of the independent claim. Advantageous developments of the present disclosure are the subject of the dependent claims.

[0023] The basic idea of ​​the proposed disclosure is to connect a medical device efficiently and securely to a central cloud system via a decentralized recording device / edge device (as a type of data transmission point or data node or intermediary). On one side of the decentralized recording device or the decentralized edge device (i.e., an on-site edge device, so to speak), a data connection is established via a secure data connection, for example via a data cable, which is connected to the medical device as well as to the edge device, and on the other side of the edge device, a conventional network connection is established, for example wirelessly via WLAN or LTE, which operates in particular using a TCP / IP network protocol and thus does not represent a local wired data connection within the meaning of the present disclosure. The local wired data connection is designed in particular toadapted to provide a memory or storage area for data.

[0024] In other words, according to the present disclosure, a medical security system for maintaining or configuring a medical device is provided, comprising: the medical device, in particular a blood treatment machine and / or a medical robot with an internal control unit, which, for example, guides an endoscope or a microscope head of a surgical microscope as an end effector, preferably a plurality of different medical devices; at least one mobile decentralized recording device with a screen, in particular an edge device in the form of a tablet, which is provided on-site in a medical facility with the medical device; and a central data processing unit, in particular a cloud server.

[0025] According to the present disclosure, the medical security system is specifically adapted to establish a two-stage data connection comprising: a first digital data connection as a secure data connection between the decentralized recording device and the medical device, and a second digital data connection as a network data connection between the central data processing unit and the decentralized recording device. The secure data connection can be a local, wired data connection outside of a network (via the second digital data connection or the network data connection). This enables secure installation of new software and documentation specifically for the medical device (individually) or secure uploading of so-called log files, i.e. data for documentation, from the medical device (via the decentralized recording device) to the central data processing unit.

[0026] In still other words, the present disclosure comprises three essential components;

[0027] - a (central) data processing unit (server), in particular a cloud server, for managing, in particular, device-specific installation files (software distribution application) or log files (service application) or connectivity features of medical devices.

[0028] - At least one (cloud) edge device that is connected or connectable to the central data processing unit (cloud server) via a network connection, preferably wireless. This edge device is preferably adapted to synchronize the specified (large) data or files in such a way that the edge device can also operate without a network connection. The edge device preferably offers the same connectivity / interface functions as the cloud server, which can be used in a local environment.

[0029] - at least one medical device that is not directly connected to a network or the cloud or cloud server, in particular a large number of medical devices.

[0030] According to a preferred embodiment, the first digital data connection can be a local network connection. The local network connection can, in particular, be a LAN (local area network) connection. The local network connection can preferably be encrypted or secured. This allows for effective data exchange within a medical facility. The local network connection can be configured as a fixed installation and / or as a mobile connection.

[0031] According to a preferred embodiment, the second digital data connection can be a preferably encrypted global network connection. The global network connection can, in particular, be a WAN (wide area network) connection. The global network connection can preferably be encrypted or secured. This allows for effective data exchange across a medical facility.

[0032] According to a preferred embodiment, the first digital data connection can be established via a cable. The data connection can be established, in particular, via an Ethernet cable. This means that an Ethernet interface is formed on the medical device and / or the decentralized recording device. Alternatively, the first digital data connection can be established wirelessly, i.e., without a cable.

[0033] According to a preferred embodiment, the second digital data connection can be wireless. Alternatively, the second digital data connection can be non-wireless, i.e., wired.

[0034] According to a preferred embodiment, the medical device can contain a web server. This can provide an interface for communication with the medical device.

[0035] According to a preferred embodiment, the medical device can contain a public key of a TLS protocol that can be accessed via the web server. According to the preferred embodiment, the decentralized acquisition device can be configured to establish an HTTPS connection to the web server via a web browser using the TLS protocol. This enables a suitable method for secure data transmission. Alternatively, the decentralized acquisition device can be configured to establish an unencrypted or otherwise encrypted connection to the web server.

[0036] According to a preferred embodiment, the web server can be configured to provide the decentralized capture device with verification data in order to perform an external verification of a signed data set on the decentralized capture device. This means that the decentralized capture device receives all information required for verifying the signed data set (directly) from the medical device. This has the advantage that the medical device is protected from malicious software and, at the same time, enables reliable verification without the decentralized capture device having to meet special requirements or possess any information. Alternatively, the external verification on the decentralized capture device can be performed using verification data that already exists or is provided in another way.According to a preferred embodiment, the decentralized capture device can be configured to transmit the signed data set to the medical device only if the external verification was successful. This means that the decentralized capture device forms a filter that transmits only certain data sets to the medical device. In other words, the decentralized capture device filters the data sets that can be transmitted to the medical device. This reduces the risk of software injection and ensures that no malicious or false data is transmitted to the medical device.

[0037] According to a preferred embodiment, the decentralized recording device can have a memory that is configured to store which signed data set or which data has been or have been transmitted from the decentralized recording device to the medical device. In this way, reliable documentation can be carried out.

[0038] In other words, access occurs via Ethernet, with a web server on the medical device (medical device) supporting external verification of signed data records (digital twin + metadata or update file) on the external device (decentralized acquisition device, edge device, or service laptop). This means that a user connects their service laptop (the decentralized acquisition device) to the medical device, opens a web browser, and establishes a secure connection (TLS 1.3, user CRT / local CRT) to the medical device. A web server (on the medical device) provides JavaScript to verify secured files (secure update files, secure digital twins (device twins), etc.) and provides a list of public keys. The browser on the service laptop (decentralized acquisition device) verifies the secured files. If the verification is successful, the secured file is transferred to the medical device.Alternatively, a TLS connection can be established via USB tethering, especially when using a mobile device instead of a laptop.

[0039] In particular, the second data connection between the cloud server and the edge device can be adapted to provide sufficient security, particularly with regard to authentication and / or authorization and / or data synchronization. The first data connection between the edge device and the medical device can be classified as secure because it is a local, wired connection.

[0040] The central data processing unit can be, in particular, a (central) cloud server, a computer, and / or a central processing unit. This could be any device that (in addition to data processing by means of a processor such as a CPU) has a storage unit.

[0041] According to a preferred embodiment, the second digital data connection may include or require authentication and / or authorization and preferably further provide a synchronization function so that the data between the central data processing unit and the decentralized recording device are synchronized both online and after a temporary offline period when the second data connection is re-established.

[0042] According to a further embodiment, the medical device and / or the sensing device and / or the central data processing unit may comprise or provide a digital security certificate to confirm the authenticity.

[0043] In particular, the secure data connection can be an https data connection with SSL encryption and an associated certificate, in particular on the edge device or the central processing unit (cloud server).

[0044] In particular, local communication (data connection) can be realized by providing a standard USB mass storage profile as a "virtual USB stick." Device-specific data is preferably not exchanged, and in particular, the success or failure of the installation process, or confirmation of a correct installation or a message about a failed installation, can be efficiently and securely documented (centrally) on the corresponding cloud server (with an associated software application). For the medical safety system, it is therefore not absolutely necessary to structurally modify the medical device; it is sufficient that the medical device has the capability or a connection to communicate locally / directly with the edge device, in particular, a USB port. This can be achieved, in particular, by appropriately adapting a control unit orThe medical security system can be designed using the control units of the medical device, the edge device, and / or the central data processing unit. This is particularly advantageous for existing medical devices, as they can be upgraded to the new security standard. Furthermore, new medical devices only require standardized connectivity to ensure a high security standard and consistent documentation.

[0045] In particular, the decentralized acquisition device may provide a USB interface so that (with a USB cable) a standardized USB port on the medical device can be used to provide the first digital data connection as a local wired data connection.

[0046] Preferably, the decentralized acquisition device has a USB port, and the medical device has a USB port, which are connectable or connected to each other via a USB cable, thus establishing the local wired data connection. The decentralized acquisition device provides a profile of a USB mass storage device (USB MSC) to simulate a connected storage medium, so that the medical device recognizes / perceives / acquires the data provided on the central data processing unit and downloaded to the acquisition device via the second data connection, in particular an installation file, as local data. The edge device and the medical device are connected, in particular, with a USB cable that matches the provided USB ports.

[0047] In particular, the USB port of the medical device and / or the decentralized acquisition device (edge ​​device) can be a USB-A, a USB-B, or a USB-C port, either standard, mini, or micro. Furthermore, a USB 4.0, 3.0, 2.0, or 1.0 can preferably be used.

[0048] The medical device thus has, in particular, a local, direct communication capability via a local communication interface, preferably via a standard USB port, which particularly preferably functions as a "mass storage device" (USB MSC) class. In particular, the medical device can have a USB-A port, a USB-B port, or a USB-C port.

[0049] In particular, the edge device has one or more of the following features:

[0050] - Local direct communication capability via a local communication interface

[0051] - In particular: Standard USB port with the particularity of simulating a USB device, i.e. the Edge device can act as an external hard drive, preferably a USB-C port (since it is a mobile / tablet device),

[0052] - Providing cloud server connection capabilities within a local environment,

[0053] - Secure communication with the cloud server regarding authentication and authorization.

[0054] In particular, the medical device can have an optical device ID and the decentralized recording device can further have a camera in order to digitally record the optical device ID and to send it to the central data processing unit in the second data connection and, based on this device ID, to receive from the central data processing unit associated data, such as an installation file and / or a log file and / or a configuration file and / or recorded data, such as in particular operating data with, for example, a temperature of a sensor or a temperature of a CPU (in particular curves over time). In particular, the associated data can be transmitted in encrypted form, particularly preferably between the central data processing unit and the edge device, and very particularly preferably even between the edge device and the medical device.In particular, the central data processing unit and / or the edge device and / or the medical device comprise a (hardware) encryption unit, such as an AES (Advanced Encryption Standard) module. In particular, additional optical methods or a printed (and attached) device label can be used to automate the device identification process in the edge device at the beginning of the process. For this purpose, the edge device and the medical device require display and capture devices for information display and capture, in particular a screen and a camera.

[0055] Preferably, the unique device ID can be inserted into the name of the associated data by the central data processing unit in order to increase security by checking the associated data (does the received file name match the medical device with the device ID by comparing the device ID with (part of) the file name).

[0056] In particular, the edge device can be adapted to provide the (device-specifically correct) data, in particular file updates or software updates, for this specific medical device. Preferably, the edge device can transfer the software installation file and the log file via a standard USB mass storage profile (service USB port, user USB port for data exchange, for example, during endoscopy images).

[0057] With regard to a medical safety method for a medical device, in particular for a medical safety system according to the present disclosure, the object is achieved in that it comprises the steps:

[0058] Establishing a first digital data connection in the form of a local, wired data connection outside a network between the medical device, in particular a blood treatment machine and / or a medical robot with an internal control unit, and a decentralized recording device, in particular an edge device in the form of a tablet, which is provided on-site in a medical facility with the medical device, and establishing a second digital data connection as a network data connection between the decentralized recording device and a central data processing unit, in particular a cloud server.

[0059] According to a further embodiment, the security method may further comprise the steps:

[0060] Transferring device information from the medical device to the decentralized recording device via the first data connection,

[0061] Transferring the device information from the decentralized recording device to the central data processing unit via the second data connection,

[0062] Providing, based on the received device information, device-specific data from the central data processing unit to the decentralized recording device via the second data connection,

[0063] Providing this received device-specific data from the decentralized recording device to the medical device via the first data connection,

[0064] Processing of the provided device-specific data on the medical device with creation of a processing result, in particular a result for a software installation,

[0065] Transferring the processing result to the decentralized recording device via the first data connection,

[0066] Transferring the result of the processing from the decentralized recording device to the central processing unit via the second data connection,

[0067] Storing the result for the specific medical device in the central processing unit.

[0068] In particular, the security procedure may further comprise the following steps:

[0069] Providing unique identification metadata for a log file for device mapping from the decentralized acquisition device to the medical device,

[0070] Transferring the log file from the medical device to the decentralized

[0071] recording device,

[0072] Transferring the log file from the decentralized recording device to the central data processing unit, and storing the log file of the specific medical device in the central data processing unit.

[0073] The objects of the present disclosure are achieved with regard to the computer-readable storage medium and with regard to the computer program in that they comprise instructions which, when executed by a computer or computer system, cause the computer or computer system to carry out the security method according to the present disclosure.

[0074] Any disclosure related to the medical system according to the present disclosure also applies to the medical safety method according to the present disclosure, in particular analogously, and vice versa.

[0075] Short description of the characters

[0076] The disclosure is explained in more detail below using preferred embodiments with the aid of figures. They show:

[0077] Fig. 1 is a schematic view of a security system according to a preferred embodiment of the present disclosure;

[0078] Fig. 2 is a schematic view of a security system according to another preferred embodiment of the present disclosure, in which a USB connection is present as the local connection;

[0079] Fig. 3 is a schematic view of a security system according to another preferred embodiment of the present disclosure, illustrating the two-stage data connection between the three levels of medical device, edge device, and cloud server;

[0080] Fig. 4 is a schematic view of a medical device of the security system according to another embodiment of the present disclosure for central documentation; Fig. 5 is a flowchart of a medical security method according to a preferred embodiment of the present disclosure; and

[0081] Fig. 6 is a schematic diagram of a connection between the medical device and a decentralized detection device of the security system.

[0082] The figures are schematic in nature and are intended only to aid understanding of the disclosure. Like elements are designated by like reference numerals. The features of the various embodiments may be interchanged.

[0083] Detailed description of preferred embodiments

[0084] Fig. 1 shows a schematic representation of a medical

[0085] Security system 1 according to a preferred embodiment with three essential components, namely a medical device 2, a decentralized recording device 4 and a central data processing unit 6. The medical security system 1 is used to maintain or configure a large number of different medical devices which are stationed at different locations in different hospitals. For the explanation of the present disclosure, however, the medical security system 1 is only explained using a single medical device 2, wherein, of course, in Fig. 1, instead of this one medical device 2, another medical device can be used, which, however, uses the same data transmission system, as explained below.

[0086] In the present embodiment, the medical device 2 is a robot-guided surgical microscope located in an operating room of a hospital and can be used for a (subsequent) procedure. However, the present disclosure does not deal with medical treatment using the surgical microscope, but rather focuses on technical service of the medical device 2 and documentation for its maintenance. The security system 2 further comprises the decentralized, portable detection device 4 as an edge device (hereinafter referred to as edge device 4) in the form of a tablet with a screen, which is provided on-site in the hospital and can be portable by technical personnel from one operating room with medical devices to the next operating room with further medical devices, one of these medical devices being the medical device 2 in the form of the surgical microscope.

[0087] The security system 1 also has the central data processing unit 6 in the form of a cloud server, which can centrally store, process and provide data.

[0088] In the present embodiment, the medical security system 1 according to the present disclosure is specifically adapted to establish a two-stage data connection between the medical device, the decentralized portable detection device 4 and the central data processing unit 6 in the form of the cloud server.

[0089] Specifically, a first digital data connection is established between the decentralized recording device 4 and the medical device 2, wherein this data connection is a local, wired data connection outside of a network. Thus, a direct, local, and wired data connection to the edge device 4 is established by means of a plug and a physical connection of the medical device, which does not provide or prevents access to a network such as an intranet or internet.

[0090] Furthermore, a second digital data connection is established between the central data processing unit and the decentralized recording device, which is a (normal) network data connection.

[0091] Through the two-stage data connection with the edge device 4 as a serial transmission interface, which effectively translates between two data modalities, a secure connection can be established between the cloud server and the medical device 2, with the edge device acting as an intermediary. On the cloud server side, a secure network connection is used, and the edge device has access to both an intranet and, if applicable, an internet into which the cloud server is integrated. On the medical device 2 side, the edge device provides a secure local cable connection, preventing the medical device 2 from accessing a network or vice versa.

[0092] This allows the Edge device 4 to act as an intermediary, allowing only filtered data to pass to the medical device and vice versa. This can significantly strengthen security in the medical field, especially against cyberattacks, viruses, Trojans, and similar malware.

[0093] Fig. 2 shows a medical security system 1 according to a further embodiment, with the difference from the embodiment of Fig. 1 that a connection based on USB is used as the local first data connection.

[0094] Specifically, the decentralized data acquisition device has a USB port in the form of a USB-C port. Furthermore, the medical device also has a USB port, for example, a USB-A, USB-B, or USB-C port. A USB cable (not shown) is plugged between the two ports, connecting the medical device 2 to the decentralized edge device 4 via a USB cable, thus establishing the local wired data connection.

[0095] The decentralized recording device 4 in the form of the tablet provides a class or profile of a USB-MSC, i.e. a mass storage device, and thus simulates a storage medium, so that the medical device records the file provided on the central data processing unit and downloaded to the recording device via the second data connection, in particular an installation file, as a local file.

[0096] In particular, an installation file for the operating system of the medical device 2 in the form of the surgical microscope can be provided by the cloud server to the edge device 4 and subsequently captured by the medical device 2 as a local file and used for installation.

[0097] This has the advantage that individual USB sticks no longer need to be manually inserted from one medical device to another, which would require the user to first find the appropriate installation file from a multitude of installation files. Furthermore, a USB stick without monitoring, such as by anti-virus software on the edge device 4, is vulnerable to malware, allowing for significantly more efficient maintenance and configuration of medical devices. It also prevents incorrect installation files from being accepted by the medical device or the lack of documentation, since a data connection (indirectly via the edge device 4) is established between the medical device 2 and the central cloud server.

[0098] In this embodiment, the second digital data connection is a secure data connection which requires authentication and authorization and further provides a synchronization function so that the data between the central data processing unit and the decentralized acquisition device 4 are synchronized both online and after a temporary offline period when the second data connection is re-established.

[0099] In particular, the Edge Device 4 can download and install current operating software for the Edge Device 4 itself, so that the Edge Device is always secure and up-to-date, thus making it impossible or at least difficult for a potential attacker to intrude and change the device.

[0100] In particular, by using the standardized hardware interface in the form of the USB interface on the medical device, no changes to an existing medical device are necessary.

[0101] The present security system 1 therefore solves all current problems according to the state of the art, for example in the case where the medical device does not have a physical network connection or a built-in wireless network module such as an LTE modem, either for cost reasons or due to safety requirements, or the medical room in which the medical device is used is located in a building or in a basement where no mobile network access is possible, or wireless connections are not permitted due to possible interactions or interference with other (relevant) medical devices, or the customer does not have a network infrastructure or is not willing to provide the network infrastructure (installation and configuration effort) for a single device unit or for a temporary use of the device.

[0102] The medical security system 1 allows flexible, secure and documented maintenance or configuration of a variety of different medical devices, which may be located in different hospitals.

[0103] Fig. 3 shows a schematic view of the functioning of a medical security system 1 according to another preferred embodiment in the form of a flowchart. Seen in Fig. 3, the three essential components are shown one above the other: the medical device 2, the decentralized recording device 4, and the central data processing unit 6. The essential data processing operations then take place in these components or between these components, as explained below.

[0104] Starting with medical device 2, device 2 is started and connected to edge device 4. After this, the device information can optionally be displayed on a display of medical device 2, so that the user can visually check and verify the correct connection once again when selecting the medical device on (now) edge device 4. Device information, in particular the device model and serial number, is also transmitted between medical device 2 and edge device 4.

[0105] The edge device 4, in turn, establishes a second data connection to the cloud server 6 and sends it a request for the device-specific configuration. Based on this received device-specific configuration, the cloud server 6, in turn, provides the edge device 4 with a device-specific software area and device-specific software installation files.

[0106] On the side of the edge device 4, in turn (based on this information provided by the cloud server), a device-specific local communication with a data area and / or storage area (with unique identification metadata for a log file for device mapping) is provided.

[0107] Medical device 2, in turn, recognizes this software installation file from the edge device as a local file and starts the installation accordingly. After the installation is complete, the installation result is displayed on the display of medical device 2: "Installation successful" or "Installation failed." This installation result is also transmitted to edge device 4 by saving it on the "locally simulated USB stick."

[0108] The edge device 4 in turn provides this result to the cloud server 6, which centrally stores the installation result for exactly this device. This ensures the documentation of the current (technical) status of the specific medical device (similar to an administrator overview).

[0109] In this way, a technical manager or an automated processing system can carry out a review of the medical devices 2, since the current status is available centrally.

[0110] Thanks to this medical security system 1, no technically skilled person is even required to perform technical maintenance on the edge device 4 in the hospital. Instead, a nursing staff member, for example, is sufficient. They simply need to walk from device to device with a tablet and perform (automated) checks and updates. Only a wired connection is required, which must be established manually. The subsequent configuration process can then be carried out automatically and securely. This is particularly important for patient safety.

[0111] Fig. 4 shows another embodiment of the medical security system 1 of the present disclosure. Unlike the embodiment of Fig. 3, documentation is created based on so-called log files.

[0112] Fig. 5 shows in a flowchart a medical security method according to a preferred embodiment, in particular for a security system 1 according to the present disclosure as described above.

[0113] In a first step S1, a first digital data connection is established in the form of a local, wired data connection outside a network between the medical device 2, in particular a blood treatment machine and / or a medical robot with an internal control unit, and the decentralized recording device 4, in particular an edge device in the form of a tablet, which is provided on site in a medical facility with the medical device 2.

[0114] In a second step S2, a second digital data connection is then established as a network data connection between the decentralized recording device 4 and a central data processing unit 6, in particular a cloud server.

[0115] This establishes an indirect data connection (via the edge device 4) between the medical device 2 and the central data processing unit 6 in the form of the cloud server.

[0116] In a step S3, device information is then transmitted from the medical device 2 to the decentralized recording device 4 via the first data connection,

[0117] In a subsequent step S4, the transmission of the

[0118] Device information is transmitted from the decentralized acquisition device 4 to the central data processing unit 6 via the second, secure data connection as a network data connection. For example, the second data connection can be a secure https data connection with an SSL key. The central cloud server processes this device information accordingly and, based on this data, determines the software files or similar data required for the specific medical device, which should be transmitted to the medical device 2.

[0119] Thereafter, in a step S5, device-specific data is provided from the central data processing unit 6 to the decentralized recording device 4 via the second data connection, based on the received device information.

[0120] In step S6, these received device-specific data are provided from the decentralized recording device 4 to the medical device 2 via the first local, wired data connection.

[0121] In step S7, the processing S7 of the provided device-specific data takes place on the medical device 2 with creation of a result of the processing, in particular a result for a software installation

[0122] In step S8, the processing result is then transmitted to the decentralized acquisition device 4 via the first data connection. In particular, the medical device 2 saves the data to its USB storage device, which is simulated by the edge device 4.

[0123] In step S9, the result of the processing is transmitted from the decentralized recording device 4 to the central processing unit 6 via the second data connection, and finally the result is stored for the specific medical device 2 in the central processing unit 6.

[0124] This ensures secure software installation and documentation of processes and the current status of the medical device. Log files can also be uploaded securely, for example, if the results are available in the form of a log file. In addition to the log file, a configuration file or recorded data, such as operating data such as a sensor temperature or a CPU temperature (especially curves over time), can also be transmitted.

[0125] All this can preferably be done without any hardware changes to existing medical devices. Only a connection in the form of a USB port in particular is required.

[0126] Fig. 6 shows a schematic representation of a connection between the medical device 2 and the decentralized detection device 4 of the security system 1.

[0127] The medical device 2 has a web server 14. The web server 14 provides a JavaScript function or verification data to verify signed data records (also called SecuredFiles). In particular, the web server provides the function to verify the signed data records externally, namely on the decentralized recording device 4. Furthermore, the web server 14 provides a public key of a TLS protocol (accessible via the web server 14).

[0128] The medical device 2 has a software library 16 (also called Connect SDK). The software library 16 can contain the public key(s). In particular, the software library 16 can contain the so-called birth public key of the device and the so-called code signing public key. The web server 16 receives the public key(s) from the software library 16.

[0129] The decentralized capture device 4 has a web browser 18. The web browser 18 executes a JavaScript function to verify the signed data records. The connection between the web server 14 and the web browser 18 is preferably established via a TLS session / connection 20 (also called user CRT / local CRT).

[0130] The decentralized recording device 4 has a memory 22. The memory 22 contains the secured data records (secured update files, secured device twins, etc.). The web browser 18 accesses the memory 22. The memory 22 can store which signed data record has been transmitted from the decentralized recording device 4 to the medical device 2.

[0131] List of reference symbols

[0132] 1 Medical safety system

[0133] 2 Medical device

[0134] 4 decentralized recording device (edge ​​device)

[0135] 6 central data processing unit

[0136] 8 USB(-C) port edge device

[0137] 10 USB port medical device

[0138] 12 USB cables

[0139] 14 web servers

[0140] 16 Software library

[0141] 18 web browsers

[0142] 20 TLS connection

[0143] 22 storage

[0144] 51 Step Establish first data connection

[0145] 52 Step Establish second data connection

[0146] 53 Step Transferring device information to a decentralized recording device

[0147] 54 Step Transferring device information to central processing unit

[0148] 55 Step Providing device-specific data to decentralized recording device

[0149] 56 Step Providing device-specific data to medical device

[0150] 57 Step Processing of the provided data

[0151] 58 Step Transfer result to decentralized recording device

[0152] 59 Step Transfer result to central processing unit and save

Claims

Claims 1. A medical security system (1) for maintaining or configuring a medical device (2), comprising: the medical device (2); at least one mobile decentralized recording device (4) with a screen; and a central data processing unit (6), characterized in that the medical security system (1) is adapted to establish a two-stage data connection with: a first digital data connection as a secure data connection between the decentralized recording device (4) and the medical device (2), and a second digital data connection as a network data connection between the central data processing unit (6) and the decentralized recording device (4).

2. Medical security system (1) according to claim 1, characterized in that the first digital data connection is a preferably encrypted local network connection, in particular a LAN connection, and the second digital data connection is a preferably encrypted global network connection, in particular a WAN connection.

3. Medical safety system (1) according to claim 1 or 2, characterized in that the first digital data connection is wired, in particular can be established via an Ethernet cable, and the second digital data connection is wireless.

4. Medical security system (1) according to one of claims 1 to 3, characterized in that the medical device (2) contains a web server (14) and a public key of a TLS protocol that can be retrieved via the web server (14), wherein the decentralized recording device (4) is configured to establish an HTTPS connection to the web server (14) using the TLS protocol via a web browser (18).

5. Medical security system (1) according to claim 4, characterized in that the web server (14) is configured to provide verification data to the decentralized recording device (4) in order to carry out an external verification of a signed data record on the decentralized recording device (4).

6. Medical security system (1) according to claim 5, characterized in that the decentralized recording device (4) is configured to transmit the signed data set to the medical device (2) only if the external check was successful.

7. Medical security system (1) according to claim 6, characterized in that the decentralized recording device (4) has a memory (22) which is configured to store which signed data set has been transmitted from the decentralized recording device (4) to the medical device (2).

8. Medical security system (1) according to one of claims 1 to 7, characterized in that the second digital data connection has or requires authentication and / or authorization and preferably further provides a synchronization function, so that both online and after a temporary offline time, when the second data connection is re-established, the data between the central data processing unit and the decentralized recording device (4) are synchronized.

9. Medical security system (1) according to one of claims 1 to 8, characterized in that the medical device (2) and / or the detection device (4) and / or the central data processing unit (6) has or provides a digital security certificate to confirm the authenticity.

10. Medical security system (1) according to one of claims 1 to 9, characterized in that the medical device (2) has an optical device ID and the decentralized detection device (4) further has a camera to digitally detect the optical device ID and to transmit it in the second data connection to the central data processing unit (6) and to receive associated data such as an installation file from the central data processing unit (6) based on this device ID.

11. Medical security method for a medical device (2), in particular for a medical security system (1) according to one of claims 1 to 10, characterized by the steps: Establishing (S1) a first digital data connection in the form of a secure data connection between the medical device (2) and a decentralized recording device (4), and Establishing (S2) a second digital data connection as a network data connection between the decentralized recording device (4) and a central data processing unit (6).

12. Medical security method according to claim 11, characterized in that it further comprises the steps: Providing unique identification metadata for a log file for device mapping from the decentralized recording device (4) to the medical device (2), Transferring the log file from the medical device (2) to the decentralized recording device (4), Transferring the log file from the decentralized recording device to the central data processing unit (6), and Storing the log file of the specific medical device (2) in the central data processing unit (6).

Images