Medical device and method for remotely accessing a medical device

Abstract

The present disclosure relates to the field of medical devices, and more particularly to techniques for remotely accessing automated medical devices. According to a first aspect, the present disclosure relates to a method for remotely accessing a medical device (10) configured to perform a medical procedure. The method includes a step (S1) in which a remote communication process (PCOMM) configures at least one access criterion for remotely accessing the medical device, and a step (S2) in which a secure connection is established between the medical device and a remote system. The method further includes a step (S3) in which the remote communication process (PCOMM) receives a request to access one or more medical processes from the remote system, and a step (S5a) in which the request satisfies the configured at least one access criterion for remotely accessing the medical device (10) to forward the request to the one or more medical processes.

Description

Technical Field

[0001] The present disclosure relates to the field of medical devices, and more particularly, to techniques for remotely accessing automated medical devices in a secure manner.

Background Art

[0002] An automated medical device is a machine intended by a manufacturer to be used, either alone or in combination, for medical purposes on humans or animals. Such medical purposes may include the diagnosis, prevention, observation, treatment or alleviation of disease, injury, or handicap.

[0003] Automated medical devices are often used in the healthcare sector and are subject to a strict regulatory framework to ensure their safety and efficiency.

[0004] Generally, an automated medical device is a complex system that needs to be carefully designed to reduce the risk of malfunction that can have health implications, and is operated by a software system (such as that installed on the medical device). The software system typically comprises software configured to cause the medical device to perform medical procedures such as medical treatment or medical diagnosis. The software system also typically includes software configured to perform support procedures related to the medical procedure, such as maintenance and service functions. In some situations, it may be desirable to remotely control or access the medical device, for example to reconfigure the medical device, in order to perform a software update, or to perform a test, or for service purposes.

[0005] However, providing remote system access to medical devices can be risky because an external party may intercept the communication or otherwise interfere and attempt to take over control of the medical device. Also, a remotely accessible medical device may be subject to a denial-of-service attack where incoming requests are received at a very high rate, which can prevent critical internal components from performing the intended or designated medical procedures and / or related support procedures. Thus, introducing remote access to medical devices may put patient safety at risk by making the medical device vulnerable to various types of cyberattacks (i.e., unauthorized access).

[0006] Furthermore, it is typically difficult to introduce cybersecurity to medical devices because the performance of an automated medical device during the execution of medical procedures and related support procedures typically needs to remain unaffected. Thus, an improved method for dealing with the cybersecurity of remotely accessible automated medical devices is needed. SUMMARY OF THE INVENTION

[0007] Accordingly, it is an object of the present disclosure to avoid the limitations of the prior art associated with remotely accessing medical devices. In particular, it is an object to provide a system, method, and apparatus that provides cybersecurity for medical devices while at the same time ensuring the safety and performance of the medical procedures and related support procedures performed by the medical device.

[0008] According to a first aspect, the present disclosure relates to a method for remotely accessing a medical device configured to perform a medical treatment, the medical device being controlled by a software system. The software system includes one or more medical processes involved in the operation of the medical device and a remote communication process separate from the one or more medical processes. The remote communication process is configured to manage communication between the medical device and one or more remote systems. Further, the one or more medical processes have a higher priority than the remote communication process. The method includes the remote communication process configuring at least one access criterion for remotely accessing the medical device and establishing a secure connection between the medical device and the remote system. The method further includes the remote communication process receiving, from the remote system, a request to access one or more medical processes and forwarding the request to the one or more medical processes if the configured at least one access criterion for remotely accessing the medical device is satisfied by the request. In some embodiments, the remote communication process and the one or more medical processes being separate means that they have separate memory spaces, separate process states, and / or communicate using inter-process communication. Thus, by separating the functions related to communication with the remote system in one (or in some cases multiple) separate processes, the security processing of the communication can be simplified and enhanced. Receiving and parsing remote requests may require significant processing resources (e.g., processor power and memory), so incoming remote requests can potentially deplete important internal components from performing their tasks, e.g., performing a medical treatment or related support processes. However, having a remote communication process that operates in its own execution context and has a lower priority than other execution contexts reduces the risk of depletion of important internal components.

[0009] Furthermore, by separating the functions, there is no need to duplicate code. In an example where functions are not separated, different internal components of a medical device must be composed of appropriate code to handle network communication itself. Additionally, quality (i.e., the level of security) can be improved because it may be easier to test cyber security functions when they are separated in one (or a few) processes.

[0010] Furthermore, the method provides improved portability because a new protocol for external communication can be added in the remote communication process.

[0011] The separation of remote communication functions is also beneficial from a software development perspective, for example, when analyzing whether cyber security requirements are met. For the validation of security requirements, reviewers may only need to consider the design of a limited part of the software system.

[0012] In some embodiments, the method includes starting up a medical device. During startup, all requests to access one or more medical processes are blocked by the remote communication process. Therefore, it is impossible to attack the medical device during startup.

[0013] In some embodiments, the method includes blocking requests to access one or more medical processes that do not meet at least one configured access criterion. Therefore, unwanted (or unknown / unrecognized) requests may be blocked, thereby reducing cyber attacks. Therefore, since unwanted and invalidated requests are not processed, the system load can be reduced by accepting only desired and valid requests. In other words, the remote communication process operates as a filter (or firewall) that filters out unwanted requests.

[0014] In some embodiments, at least one access criterion includes that the sender or originator of the request is authenticated. Thereby, requests from unknown systems are blocked.

[0015] In some embodiments, at least one access criterion includes that the request has a permitted request type. Thereby, unknown or invalid access types are blocked.

[0016] In some embodiments, at least one access criterion includes that the request pertains to a permitted function. Thereby, requests to access functions for which remote access is disabled are blocked.

[0017] In some embodiments, at least one access criterion includes that the number of requests received per unit time does not exceed a threshold. Thus, if incoming requests that potentially deplete one or more medical processes are received very rapidly, they are not transferred to one or more medical processes at this rate. By blocking requests received very rapidly, the risk that critical internal components become depleted can be reduced.

[0018] In some embodiments, at least one access criterion includes individual rules for different senders, request types, and / or functions. Thereby, it is possible to precisely control which requests are permitted.

[0019] In some embodiments, configuring includes receiving configuration data from an operator and / or reading configuration data stored in a medical device, and configuring at least one access criterion based on the received configuration data. Thus, an operator can control how and by whom a medical device can be accessed. Alternatively, access may be controlled, for example, by a predetermined configuration pre-loaded into the medical device by a manufacturer or owner.

[0020] In some embodiments, transferring involves transferring the request using a protocol different from and / or independent of the protocol used for communication between the medical device and the remote system. Thus, the network used by the remote system is physically separate and not routable to the internal network of the medical device.

[0021] In some embodiments, the medical device includes a set of processors, and both one or more medical processes and the remote communication process are executed by the same one or more processors of the set of processors. Thus, remote communication may be handled by the same processor that handles safety-critical patient data as long as the remote communication is executed in a separate context. Sophisticated processors used in medical devices often incorporate support for communication with remote systems. Thus, since no additional processor is required to handle remote communication, the proposed solution can be implemented without adding additional hardware.

[0022] In some embodiments, the request to access one or more medical processes includes the request to remotely control the medical device, the request to update the software in the medical device, the request to set the time of the medical device, the request to receive log data from the medical device, the request to update the configuration of the medical device, and / or the request to update the credentials of the medical device. Thus, the proposed technique may be applied to various types of requests.

[0023] In some embodiments, the method includes giving one or more medical processes a higher priority with respect to the processing capacity of the medical device than the remote communication process. Thus, the operation of medical procedures and related support procedures always has the highest priority.

[0024] According to a second aspect, the present disclosure relates to a medical device for performing a medical treatment, the medical device comprising a set of processors, a set of memory units storing a software system for execution by the set of processors, and a communication interface enabling communication with one or more remote systems. The software system is configured to operate the medical device to perform a medical treatment and related support procedures when executed by the set of processors. The software system includes one or more medical processes involved in the operation of the medical device and a remote communication process separate from the one or more medical processes. The remote communication process is configured to manage communication between the medical device and the one or more remote systems, and the one or more medical processes have a higher priority than the remote communication process. Further, the software system is configured to execute the method according to the first aspect when executed by the set of processors.

[0025] According to a third aspect, the present disclosure relates to a computer-readable medium comprising a software system for remotely accessing a medical device for performing a medical treatment. The software system includes one or more medical processes involved in the operation of the medical device and a remote communication process separate from the one or more medical processes. The remote communication process is configured to manage communication between the medical device and the one or more remote systems. Further, the one or more medical processes have a higher priority than the remote communication process. Further, the software system is configured to execute the method according to the first aspect when executed by a set of processors of the medical device.

Brief Description of the Drawings

[0026]

Figure 1a

Figure 1b

Figure 1c

Figure 2a

Figure 2b

Figure 3

Figure 4

Figure 5

[0027] Reference will now be made to the accompanying drawings, which show some, but not all, embodiments of the invention. Embodiments of the invention will now be described more fully hereinafter. In fact, the solutions of the present invention may be implemented in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like reference numerals refer to like elements throughout.

[0028] This disclosure proposes that all interactions and functions in a medical device that manage communication with a remote system are architecturally separated in a separate software process (or software component), herein called the remote communication process, that runs in a separate context. This abstracts the cyber security details from the internal software processes that handle medical applications and also prevents the internal software processes from knowing the details of the communication protocol. The remote communication process component can also reduce system load by accepting only the desired and valid requests. For example, in some embodiments, requests from the remote system are serviced only at a safe speed for the medical device and are transferred to the internal software processes of the medical device. Invalidated requests and communication denials are done, for example, by configuring the medical device's firewall defensively, which is an efficient design that reduces performance needs. Thus, the proposed remote communication process is separated from the rest of the one or more medical processes and is different from a standard interface in that it has a low priority. The remote communication process is not involved in the execution of medical procedures and basically handles only remote communication. All incoming requests need to pass through the remote communication process. As a result, even if the remote communication process is attacked and compromised, the medical procedure is not affected.

[0029] To better understand the proposed technology, some exemplary medical devices are first described. A medical device is an automated device or machine configured to operate, optionally in combination with one or more other medical devices, to perform a medical procedure on a human or animal subject. As used herein, a medical procedure may include one or more of the diagnosis, prevention, observation, treatment or alleviation of a disease, injury, or handicap, or observation for the detection thereof.

[0030] FIG. 1a illustrates two exemplary medical devices 10, 10' that may be involved in a medical procedure for performing extracorporeal blood treatment as part of a renal function replacement therapy such as, for example, hemodialysis, hemodiafiltration, hemofiltration, or isolated ultrafiltration. The medical device denoted by 10 is a blood treatment device, which includes, for example, a blood collection line 11A and a blood return line 11B for connecting to the circulatory system of subject 100 at a vascular access. As indicated by the arrows, the medical device 10 is operable to draw blood from the subject 100, process the blood within a dialyzer (not shown), and return the processed blood to the subject 100 in a manner controlled, for example, by a blood pump. In the dialyzer, blood passes through one side of a semipermeable membrane and dialysis fluid passes through the other side of the membrane. The membrane allows waste particles and water to move from the blood to the dialysis fluid and allows desired particles to move from the dialysis fluid to the blood. The blood treatment device 10 may also include a syringe driven by a syringe pump, and the syringe is used for heparin injection or calcium injection. The medical device denoted by 10' is operable to prepare the fluid used by the blood treatment device 10 and includes a fluid line 11 for supplying the fluid to the blood treatment device 10. In one example, the medical device 10' is a water preparation device and the fluid is purified water. For example, the water treatment device 10' may filter incoming water by reverse osmosis, as is known in the art.

[0031] In the example being described, the medical device 10 includes a display 12 (optionally a touch display), a control button 13 (one is shown), an indicator lamp 14, a loudspeaker 15, a control system 16, one or more actuators 17 for performing a controlled collection, processing, and return of blood to the subject 100 via the blood collection line 11A and the blood return line 11B, and one or more sensors 18 for providing sensor data indicative of the medical procedure being performed by the blood treatment device. The medical procedure may also include, for example, priming and functional checks. The actuators 17 and sensors 18 may include internal components (shown in dashed lines) of the medical device 10, external components, or both.

[0032] Actuator 17 is configured, for example, to control a valve, a pump, and / or a heater while a medical treatment is being performed. In other words, actuator 17 is configured to control a medical treatment. Actuator 17 and sensor 18 may also include auxiliary sensor 18' and auxiliary actuator 17' that are used to monitor the medical treatment and, in some cases, perform preventive actions. Auxiliary actuator 17' is configured, for example, to control an emergency valve or an emergency brake for interrupting a medical procedure. For example, to change the fluid flow rate, the user typically enters a set value for the fluid flow rate on a display 12, for example via a graphical user interface (GUI) generated thereon, or by using control buttons 13. This set value is then converted into one or more actuator set values, i.e., values that control the corresponding actuator. For example, a fluid flow rate (set value) of 300 ml / min is converted into, for example, a pump speed (actuator set value) in rpm or percent.

[0033] Control system 16 is configured to adjust the operation of actuator 17 and sensor 18 and to obtain user input via control buttons 13 in order to perform the intended medical treatment of the blood treatment device and, as necessary in connection with the medical treatment, to operate display 12, indicator lamp 14, and loudspeaker 15. For example, display 12 may be operated to present instructions to the user of medical device 10, indicator lamp 14 may be operated to indicate the state of the medical device, and loudspeaker 15 may be operated to generate an alarm signal or the like.

[0034] Medical device 10 is connected to a remote system 20 ( one only one is shown, but there may be multiple). Remote system 20 is configured, for example, to remotely monitor and / or control the medical device. Remote system 20 is further described in FIG. 2b.

[0035] Medical device 10' may have a set of components similar to medical device 10 at the level of detail being described, and will not be described further. Medical device 10' is also connected to remote system 20, similar to medical device 10. Medical devices 10, 10' may include more components than shown, which are not described in this document for brevity.

[0036] Figure 1b illustrates another exemplary medical device 10 that is operable to transport dialysate into the peritoneal cavity of subject 100 in a controlled manner and then remove the dialysate therefrom, as indicated by the double-headed arrow. This medical procedure is generally known as automated peritoneal dialysis, and medical device 10 is often referred to as a "PD cycler". A PD cycler includes, for example, a pump for any of mixing, transporting, and removing dialysate. Medical device 10 of Figure 1b may have a similar (but typically reduced) set of components at the level of detail being described as compared to medical device 10 of Figure 1a, and may also be connected to remote system 20. Medical device 10 of Figure 1b may include more or fewer components than shown, which are not described in this document for brevity. Medical device 10 may also be connected to another medical device 10', as shown in Figure 1a, to obtain purified water used to mix the dialysate.

[0037] Figure 1c illustrates a further exemplary medical device 10 that is operable to transport a medical fluid to a body of a subject 100, such as a human, in a controlled manner, e.g., to a circulatory system of the subject 100, as indicated by the arrows. The medical fluid may be any suitable fluid including, but not limited to, drugs and / or nutrients. This type of medical device 10 is generally known as an "infusion pump". One or more actuators of the infusion pump are configured to control one or more pumps to deliver drugs and / or nutrients to the subject 100 at a specified rate. A line occluder and / or valve is actuated to control the fluid flow rate during pumping. The medical device 10 of FIG. 1c may have a similar (but typically reduced) set of components and may be connected to the remote system 20 as the medical device 10 of FIG. 1b at the level of detail described and will not be further described. The medical device 10 of FIG. 1c may include more components than those shown, which are not described herein for the sake of brevity.

[0038] FIG. 2a describes in more detail a control system 16 of any of the exemplary medical devices of FIGS. 1a - c according to one exemplary embodiment. The control system 16 includes a processor 161, a communication interface 162, and a memory 163. The processor 161 may be any commercially available processing device such as a central processing unit (CPU), a digital signal processor (DSP), a microprocessor, a microcontroller, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or a combination thereof.

[0039] The communication interface 162 is configured to enable communication with the remote system 20 (Figs. 1a - c). The communication may be wireless and / or wired. Wired communication may be performed using a wired Ethernet® connection, RS - 232, RS - 485, or UART. Wireless communication may be performed via Bluetooth®, WiFi®, Zigbee®, Z - Wave®, wireless universal serial bus (“USB”), any of the infrared protocols, or other suitable wireless communication technologies. The communication interface 162 is, for example, a Bluetooth chip configured to be controlled by the processor 161. Communication between the remote system 20 and the medical device may be performed using any suitable communication protocol, such as the Internet protocol or a proprietary protocol. In some embodiments, the communication interface may implement secure communication using, for example, a pre - shared key approach, implement secure DNS communication using SSL / TLS, implement secure DHCP communication using delayed authentication and pre - shared keys, and implement other application - specific protocols using SSL / TLS.

[0040] Memory 163 may include, but is not limited to, read-only memory (ROM), programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), flash memory, removable memory, random access memory (RAM), dynamic random access memory (DRAM), static RAM, cache memory, hard drive, storage media, etc., and may include non-volatile memory or volatile memory, or a combination thereof. Memory 163 stores a software system for execution by processor 161. The software system is an integrated collection of software items arranged to implement a particular function or set of functions. See ISO standard IEC62304 for medical devices. The software system includes application software and a software platform (typically including an operating system) that manages the software application and functions as an intermediary between the application of the medical device and the hardware. The software system may be accessed by remote system 20 via communication interface 162.

[0041] The software system is specified by one or more instructions stored in memory 163 that are executable by processor 161 to perform the operations described herein. The software system is configured to control medical device 10, for example, to perform a medical procedure. In other words, the software system includes one or more medical processes P MED involved in the operation of medical device 10. The software system is also configured to perform the method of the first aspect (Figure 4), described in detail below, when executed by processor 161.

[0042] Processor 161 and memory 163 are "separate" in the sense that they are individually operable units, but they may be arranged in any combination on a common substrate, such as an integrated circuit, or may not be arranged. For simplicity, control system 16 of FIG. 2a is shown as including only one processor 161 and one memory 163. However, it should be understood that medical device 10 may include a set of processors including one or more processors 161, and memory 163 may be implemented by one or more storage devices.

[0043] FIG. 2b further details an exemplary remote system 20. Remote system 20 is any system that is not an integrated part of a medical device, and more specifically, is a software system executed by a set of processors 161 of control system 16 of medical device 10. Remote system 20 is, for example, a service or support system. Remote system 20 may include one or more of a server, a workstation laptop, a computer, etc. The remote system may be located on-site or off-site. In its simplest form, the remote system is a simple user device, such as a tablet or personal computer, which has software configured to remotely access medical device 10 installed therein. Remote system 20 includes a processor 21, a communication interface 22, and a memory 23. Processor 21 may be any commercially available processing device, such as a CPU, a DSP, a microprocessor, an FPGA, an ASIC, or any other electronic programmable logic device, or a combination thereof.

[0044] The communication interface 22 is configured to enable communication with the medical device 10. The communication may be wireless and / or wired. Wired communication may be performed using a wired Ethernet connection, RS-232, RS-485, or UART. Wireless communication may be performed via any one of Bluetooth, WiFi, Zigbee, Z-Wave, wireless universal serial bus (``USB''), infrared protocol, or other suitable wireless communication technologies. The short-range communication interface 22 is, for example, a Bluetooth chip configured to be controlled by the processor 21. Communication between the remote system 20 and the medical device 10 may be performed using any suitable communication protocol such as the Internet protocol or a proprietary protocol.

[0045] The memory 23 may include non-volatile memory or volatile memory, or a combination thereof, including but not limited to ROM, PROM, EEPROM, flash memory, removable memory, RAM, DRAM, SRAM, cache memory, hard drive, storage media, etc. The memory 23 stores software for execution by the processor 21. The software is configured to control the medical device 10, for example, to perform services and support.

[0046] For simplicity, the remote system 20 in FIG. 2b is shown as having only one processor 21 and one memory 23. However, it should be understood that the remote system 20 may include several processors, and the memory 23 may be implemented by one or more storage devices.

[0047] The remote system 20 is configured to receive information, such as sensor data provided by the sensor 18, from the medical device 10 via the communication interface 22. The remote system 20 may also transmit information to the medical device 10 to remotely access the medical device 10 for various purposes, for example. Communication is typically carried out using messages communicated via the communication interface 22. The messages may indicate various commands (access requests) or may carry data (e.g., remote requests).

[0048] To separate treatment from other types of operations, medical devices can often operate in different modes, such as a treatment mode and a service mode. The service mode is typically used for procedures that are not treatment, such as for service or support. One example of remote access is that the remote system 20 can access the medical device 10 to set the medical device 10 to the service mode. Another example is that the remote system 20 can request the medical device 10 to send service mode data to the remote system 20 or to change settings such as language, alarm thresholds, etc. The service mode data may include information about the current settings of the medical device 10, information about the last maintenance performed, information about the installed software version, etc.

[0049] Remote access may also be used by the remote system 20 to execute a software update on the medical device 10. This may be done by transmitting information that updated software is available, and this may be done in the treatment mode. Thereafter, the operator may be informed about the available software update, for example via the display 12. Thereafter, the operator can trigger the download and installation of the software update at an appropriate time. Remote access may also be used to install the updated software on the medical device 10.

[0050] Another example of remote access is remote access to the actuators 17 of the medical device or internal procedures for various purposes. In fact, any procedure of the medical device 10, and even the medical treatment itself, can be performed remotely.

[0051] Here, with reference to FIGS. 3 to 5, the proposed technology will be described.

[0052] FIG. 3 is a block diagram of an exemplary software system configured to control a medical device 10 according to a non-limiting example of the proposed technology.

[0053] The software system to be described includes four subsystems represented as SS1 to SS4. The subsystems SS1 to SS4 may be considered software modules of computer-executable instructions independently developed and testable to provide specific functions regarding the operation of the medical device when performing medical procedures and support procedures. Each individual subsystem is composed of software processes (or threads) executed within the context of the individual subsystem. Thus, the software processes within the subsystem may be designed to execute a group of adjusted processes to provide a specific function of the subsystem. The software processes (or simply processes) in this book refer to software components including a sequence of instructions that can be independently managed by a scheduler, and the scheduler is typically part of the operating system of the software system executed by the processor 161 of the control system 16 of the medical device 10. The implementation of the process varies depending on the operating system. Different processes usually do not share resources such as memory space. The software processes are, for example, Linux (registered trademark) processes or Green Hills Integrity processes. The operating system typically includes a standard firewall such as Netfilter that monitors and controls incoming and outgoing network traffic based on certain security rules.

[0054] It is also conceivable that the subsystem includes one or more processes not involved in the execution of the medical treatment. Further, the subsystem may include additional software components such as middleware and / or low-level software components that perform basic functions or services in a software system, such as a communication stack for managing communication with other subsystems, an error manager for managing technical errors, a notification manager for managing notifications, and the like. One or more of the subsystems may operate on one or more operating systems to utilize the services provided by the operating system with respect to hardware and software resources. Depending on the implementation, the operating system of the subsystem of the software system executed by the processor 161 may include, for example, a real-time operating system, an embedded operating system, a single-tasking operating system, or a multi-tasking operating system, or any combination thereof.

[0055] The software processes related to the proposed technology are described with reference to the exemplary architecture of FIG. 3. The first subsystem SS1 comprises one or more medical processes P configured to execute a medical treatment, such as a dialysis treatment, or a support procedure, so as to control the operation of the medical device. MED Accordingly, one or more medical processes P MED may include processes configured to control the operation of the medical device 10 related to the medical treatment, such as support and / or services. Accordingly, the first subsystem SS1 is referred to herein as the main system of the medical device 10.

[0056] The main system SS1 also comprises a remote communication process P COMM Accordingly, the remote communication process P COMMis configured to manage communication between the medical system 10 and one or more remote systems 20. In other words, the remote communication process P COMM is responsible for establishing a secure (authenticated and encrypted if applicable) connection to the remote system 20. The remote communication process P COMM is also responsible for communicating with the remote system 20. All communication with the remote system 20 is through the remote communication process P COMM within the main system SS1, so that remote access to the functions of one or more medical processes P MED is always through the remote communication process P COMM In other words, all requests to remotely access one or more medical processes P MED or other processes of the main system are routed through the remote communication process P COMM (i.e., received through or entering through the remote communication process P).

[0057] Even if the medical device 10 used to illustrate the proposed technology includes a single remote communication process P COMM in other examples, it should be understood that there may be two or more remote communication processes P COMM For example, a medical device may include multiple remote communication processes P COMM to handle various types of remote requests and / or protocols. In this case, as described above, each one of these remote communication processes P COMM must be separated from one or more medical processes P MED and have a lower priority than one or more medical processes P MED .

[0058] The remote communication process P COMM is for one or more medical processes P MEDIt is separate. That the processes are separate means, for example, that they have separate memory spaces, individual process states, and / or communicate using inter-process communication. In other words, this concept is about separating one process (or, in some cases, multiple processes) that handles remote communication, here P COMM , and this is restricted in terms of what is permitted to be done. In some embodiments, the remote communication process P COMM cannot access system resources except for what is necessary for communication with the remote system. In some embodiments, its only task is to process valid requests. Henceforth, only one remote communication process P COMM will be discussed. However, if there are multiple remote communication processes P COMM , the same requirements apply to each of them.

[0059] As described above in connection with FIG. 2a, the medical device 10 may include one or more processors 161. Since the processes are separate, one or more medical processes P MED and the remote communication process P COMM may be executed by the same one or more processors and still remain separate. In other words, an error in one process does not propagate to the other process.

[0060] Furthermore, one or more medical processes P MED have a higher priority than the remote communication process P COMM . This is because the software system, for example, from the perspective of processing power and memory access, one or more medical processes P MEDmeans always giving priority. Specifically, a priority is assigned to each process. The concept of process priority is well-known in computer science. This concept means that a process with the highest priority is executed or allocated resources before any process with a lower priority. Processes with the same priority are executed, for example, in a first-come, first-served order. The priority can be determined based on memory requirements, time requirements, or other resource requirements. Therefore, if there is an overload in the telecommunication process P COMM it will not affect one or more medical processes P MED

[0061] As a further example, the telecommunication process P COMM is not permitted to access a given file. However, one or more medical processes P MED may be permitted to access the given file.

[0062] Many medical devices that perform medical treatments that pose a health risk to a subject in the event of an operating failure in either the main system that controls the medical treatment or any of the hardware components used by such a main system operate in parallel and may include a protection system (also called a supervision system) that is independent of the main system. Whenever the protection system detects a potential operating failure, the medical device is switched to a safe operating state. Therefore, in this example, the third subsystem SS3 includes a supervision process P S configured to supervise the operation of the medical treatment. The third subsystem SS3 is also referred to in this document as the protection system of the medical device 10.

[0063] ​Subsystems SS2 and SS4 are I / O systems respectively configured to communicate with various sets of actuators 17 and / or sensors 18 of the medical device 10 based on commands / signals generated by the main system SS1 and the protection system SS3. To this end, each of the subsystems SS2, SS4 may comprise a software process for providing access to peripheral devices (e.g., actuators 17 and / or sensors 18 (Figs. 1a - c)) connected to the respective subsystems SS2, SS4. In Fig. 3, these processes are shown as P I / O (abbreviation for I / O process) and P S‐I / O (abbreviation for supervisory I / O process).

[0064] The processes of subsystems SS1 - SS4 communicate using inter - process communication (IPC), which refers to the mechanism of the operating system that enables processes to manage shared data. Inter - process communication typically uses a message - based protocol. For example, inter - process communication uses clients and servers, where the client requests data and the server responds to the client's request. The design of inter - process communication depends on the implementation.

[0065] In this example, each subsystem also comprises an individual internal communication process P I‐COM . The communication process P I‐COM is responsible for routing requests to modify the receiver and maintaining an active communication session, and for handling, for example, communication between processes of different subsystems SS1 - SS4. Since all communication with the remote system 20 is performed via the remote communication process P COMM within the main system SS1, remote access to the functions of the other subsystems SS2 - SS4 is processed by the communication process P I‐COM , in other words, all requests to remotely access the medical device 10 are routed or passed through the remote communication process P COMM of the main system SS1.

[0066] Note that the proposed technology can be similarly implemented even in medical devices that do not include the protection system SS3 and the corresponding I / O system SS4. Also, it is possible that the I / O system has a design integrated into the main system SS1 and the protection system SS3 (if present), rather than being a separate subsystem. Therefore, the subsystems SS2, SS3, and SS4 are shown by dashed lines in FIG. 3.

[0067] Here, with reference to the flowchart of FIG. 4, the proposed technology will be described in more detail. FIG. 4 illustrates an exemplary method for remotely accessing a medical device 10 configured to perform a medical procedure, such as the medical device 10 of any of FIGS. 1a - 1c. This method is executed, for example, in a medical device 10 disposed in a medical environment such as a hospital where the medical device 10 is used to treat a patient, for example. This method may also be executed in a medical device 10 in a patient's home. This method enables a remote system (and an operator of such a system) located inside or outside the medical environment to access the machine in a secure manner, for example, to diagnose the medical device 10.

[0068] As described above, the medical device 10 is controlled by a software system, one or more medical processes P involved in the operation of the medical device 10 MED and a remote communication process P COMM The remote communication process P COMM is configured to manage communication between the medical system 10 and one or more remote systems 20. The remote communication process P COMM is separate from one or more medical processes P MED Furthermore, one or more medical processes P MED have a higher priority than the remote communication process P COMM as described in connection with FIG. 3.

[0069] This method is typically implemented as a computer program comprising instructions for causing a computer to execute the method when the program is executed by a set of processors. According to some embodiments, the computer program is stored on a computer-readable medium comprising instructions for causing a computer to execute the method when the program is executed by a set of processors.

[0070] This method may be executed at any time when the medical device 10 is switched on. A prerequisite for being able to execute the method is typically that the communication interface 162 of the medical device 10 is enabled.

[0071] When the medical device is switched on, a startup procedure is initiated. In some embodiments, the method comprises a step S0 of starting up the medical device 10, which is typically performed when the medical device 10 is powered on. All requests from the remote system 20 (i.e., incoming request messages) are typically rejected until the startup procedure is completed. In other words, in some embodiments, a request to access one or more medical processes P MED is blocked by the remote communication process P COMM during startup S0. That a request is blocked means that they are discarded or, in some cases, stored until the startup procedure is completed.

[0072] During startup, the remote communication process P COMM configures at least one access criterion for remote access to the medical device 10 in S1. For example, the communication settings of the remote system 20 are configured in the medical device 10. The configuration data may be received from an operator via the GUI of the medical device 10. Alternatively, the configuration data stored in the medical device 10 may be read out by the remote communication process P COMM Thus, the configuration data may be added during manufacture or when the medical device 10 is used.

[0073] The communication settings include, for example, the IP address of the remote system to which the medical device 10 needs to access. It may also include the address of the remote system 20 that is permitted to access the medical device. In this example, the IP address of the remote system 20 may be configured within the medical device 10. In some embodiments, unregistered devices are not permitted to access the medical device 10.

[0074] In addition to or instead of this, the communication settings may include authentication data for verifying the authenticity of the remote system 20. In other words, in some embodiments, the credentials used by the remote system 20 are configured within the medical device 10. This may include, for example, credentials configured within the medical device 10 and shared by the remote system 20 using, for example, public-key cryptography. In this way, the medical device 10 may ensure that a particular remote system 20 is trusted and should be permitted to access the medical device 10. In other words, in some embodiments, at least one access criterion includes that the sender or originator of the request is authenticated. For example, a request to remotely access the medical device 10 must be signed with an encryption key known to the medical device 10 in order to be accepted.

[0075] Furthermore, a predetermined function of the medical device is enabled for remote access by the remote system 20. For example, the remote system 20 can read a predetermined sensor 18, control a predetermined actuator 17, or execute a predetermined command. In other words, at least one access criterion includes that the request has a permitted request type or that the request relates to a permitted function. For example, the permitted request type may include a request to perform an SW update, or the request may include a request to receive log data from the medical device 10.

[0076] In other words, in some embodiments, at least one access criterion includes individual rules for different senders, types of requests, and / or functions.

[0077] Also, the remote communication process P COMM may be configured not to transfer requests at a rate that could damage the system. In other words, the remote communication process P COMM may be configured to always transfer requests at a safe rate. In this way, in the case of a denial-of-service attack, other processes of the medical device 10 are prevented from starving. Resource starvation is a problem that occurs in parallel computing. For example, the operating system may not always be able to provide the resources required by a process (such as memory and computing resources) for that process to execute its task. Starvation of the medical device 10 can be intentionally caused by the remote system 20 by sending a large number of requests to the medical device 10 and causing the medical device 10 to allocate its resources to request processing instead of performing a medical procedure. In other words, in some embodiments, at least one access criterion includes that the number of requests received per unit time does not exceed a threshold. The threshold is, for example, the number of requests per second that depends on the reception capacity of the remote communication process P COMM Typically, it is about 1 or a few dozen per second. The rate may be defined for each request type or function.

[0078] The configuring S1 may be done when setting up the system or at a later point in time. In some embodiments, the medical device 10 is reconfigured and, for example, another remote system may be configured by an operator via a GUI to be an approved (or trusted) remote system as needed.

[0079] To remotely access a medical device, a connection needs to be established between the medical device 10 and the remote system 20. The connection is typically a secure connection established by exchanging credentials or for exchange using a VPN connection. The connection may be encrypted. More specifically, a remote connection is established between the communication interface 162 of the medical device 10 and the communication interface of the remote system 22. The connection may be an IP connection using, for example, different underlying transport protocols. The connection may use wireless or wired communication, or a combination thereof. In some embodiments, the connection is established via the Internet with, for example, a remote system 20 located at another location. Thus, the connection may be subject to cyberattacks. In other words, the method is a remote communication process P COMM includes establishing a secure connection S2 between the medical device 10 and the remote system 20.

[0080] When the remote system 20 desires to access the medical device 10, the request is typically sent to the medical device 10. The request is received by the remote communication process P COMM Thus, the method includes the remote communication process P COMM receiving a request (i.e., a message) S3 from the remote system to access one or more medical processes P MED The medical device may support requests having various formats depending on the purpose. Typically, the medical device 10 has one or more protocols configured to be supported by the remote system 20. However, the request typically includes a request type and, optionally, further (or alternatively) an internal destination within the medical device such as a sensor or internal function. Additionally, the request may include data such as set values or other parameters.

[0081] Various types of requests may be received from the remote system 20. In some embodiments, the request to access one or more medical processes includes a request to remotely control the medical device 10. Remote control may be used, for example, for servicing or supporting the medical device 10. In some embodiments, the request to access one or more medical processes P MED includes a request to update the software within the medical device 10. This type of access may require additional security measures. In some embodiments, the request to access one or more medical processes includes a request to set the time of the medical device 10, or a request to receive log data from the medical device 10. In some embodiments, the request to access one or more medical processes includes a request to update the configuration of the medical device 10. The configuration may be related to the remote access configuration (see step S1). In some embodiments, the request to access one or more medical processes includes a request to update the credentials of the medical device 10.

[0082] However, the remote communication process P COMM does not forward requests that do not meet at least one configured access criterion. Thus, the method includes the remote communication process P COMM evaluating whether the received request meets at least one configured access criterion for remote access to the medical device 10 S4.

[0083] If the request meets the pre-determined criteria, for example, if the remote system 20 can authenticate itself and the request is received at a secure rate, the request is forwarded to the relevant software process. In other words, the method includes the remote communication process P COMM forwarding the request to one or more medical processes P MED if the request meets at least one configured access criterion for remote access to the medical device 10 S5a. In other words, the remote communication process P COMMincludes a filter for incoming requests.

[0084] Remote communication process P COMM typically receives requests from a remote system using a standardized protocol such as IP. However, typically, internally within the machine, another protocol, such as the manufacturer's proprietary protocol, may be used. In other words, in some embodiments, the remote communication process P COMM uses a protocol different from and / or independent of the protocol used for communication between the medical device 10 and the remote system 20 to forward requests. This means that the external communication with the remote system 20 and the internal communication within the medical device 10 are not directly routable, but the remote communication process P translates and / or converts the requests to the protocol used for internal communication and also checks that at least one configured access criterion is met. COMM always means going through.

[0085] As described above, in situations where the remote communication process P COMM requires a large amount of processing power, it is important that one or more medical processes P MED do not become depleted. Therefore, the operation of one or more medical processes P MED has the highest priority. In other words, in some embodiments, the method gives one or more medical processes P MED a higher priority with respect to the processing power of the medical device 10 than the remote communication process P COMM . This may be implemented by assigning a higher priority to one or more medical processes P MED in the operating system.

[0086] Requests that do not meet the access criteria are typically blocked by the process P COMM . In other words, in some embodiments, the method is such that the remote communication process P blocks one or more medical processes P that do not meet at least one configured access criterion.MED including blocking the request to access S5b. Blocking means that they are not transferred to other processes within the medical device 10. In some scenarios, blocking may be temporary. For example, if the request is received at an unsafe speed, the request may be blocked for a while (e.g., in a buffer) and then transferred at a safe speed. Therefore, the time in the buffer depends on the incoming speed and the safe speed.

[0087] Since it is not desirable for a malicious remote system to obtain that type of information, the remote system 20 is typically not informed whether the request has been blocked.

[0088] Thereafter, steps S3 - S5 may be repeated for incoming requests to access the medical device 10 until a secure connection between the medical device 10 and the remote system 20 is terminated, for example, via a GUI or the connection is terminated in some other way. The connection may further (or alternatively) be automatically terminated / stopped when a "transaction" between the remote system 20 and the medical device 10 is completed.

[0089] Figure 5 is a sequence diagram of internal signaling between processes of the main system SS1 of the medical device 10 when implementing the proposed method according to an exemplary implementation.

[0090] This exemplary implementation also refers to the medical devices of FIGS. 1a - 1c and the exemplary software architecture (in particular, the main system SS1) described in connection with FIG. 3 above.

[0091] The first subsystem SS1, also called the main system, is implemented by a plurality of SW items that manage different functions of the medical device 10. The SW items are functional parts of the software architecture. The SW items can be deployed by one or more software processes. Alternatively, a software process may implement one or more SW items. For the sake of simplicity, only the SW items involved in the proposed method for remotely accessing the medical device are shown in FIG. 5.

[0092] The main system SS1 includes, in addition to one or more medical processes P MED (not shown in FIG. 5), remote system communication, a configuration manager, and a credentials manager. In this example, all processes except the RSC implemented by two SW items are implemented by one corresponding SW item.

[0093] The configuration manager is responsible for managing the configuration parameters within the system. The configuration manager stores the configuration parameters, updates them in response to requests, records the updates in a log, and provides the configuration parameters to the client.

[0094] The credentials manager is responsible for storing cyber security credentials such as certificates, private keys, and public keys, and for providing the credentials to the client.

[0095] The remote system communication RSC corresponds to the remote communication process P COMM described above. Thus, the RSC is responsible for establishing a secure (authenticated and encrypted if applicable) connection to the remote system 20. The RSC is also responsible for data communication with the remote system 20. In this example, the RSC is split into the following SW items. · RSC manager: responsible for activating the enabled functions (read from the configuration manager) for the remote system and converting them into an internal protocol. ·RSC Transport: Generally responsible for the format and encryption of external protocols.

[0096] Remote system communication is typically an internal SW item from the client to the device. Thus, since the medical device internal SW items typically do not depend on the existence of remote system communication, remote system communication does not act on the server.

[0097] Here, referring to FIG. 5, an example of signaling between processes within the main system SS1 during the setup of a secure connection is described.

[0098] Typically, several preconditions need to be met before activation begins. For example, the IP (Internet Protocol) settings need to be configured in the configuration manager via a GUI or the like. Further, typically, a predetermined function for remote access should be enabled / disabled either via the remote system 20 or the GUI. Alternatively, there may be a default configuration that may be used. Further, the encryption key used for the secure connection is installed in the medical device, for example, during manufacturing.

[0099] First, while the medical device 10 is booting, all requests received from the remote system 20 (step 50) are typically blocked by a firewall (in the RSC Transport) (step 51). These steps correspond to step S0 in FIG. 4.

[0100] When the medical device 10 starts up and operates (i.e., when the boot is complete), the RSC manager reads the IP settings and the enabled communication functions from the configuration manager (step 52) and reads the credentials from the credential manager (step 53). Thereafter, the RSC manager requests the RSC transport to initiate a secure connection using the provided credentials and the enabled communication functions (step 54). Accordingly, the RSC transport configures the firewall to accept only the ports and protocols used by the currently enabled communication functions received from the RSC manager (step 55). At least one access criterion for remotely accessing the medical device 10 is configured here in the RSC transport. Accordingly, these steps correspond to step S1 in FIG. 4.

[0101] To establish a secure connection, the remote system 20 first needs to authenticate itself using the credentials received from the RSC manager (step 56). Thereby, a secure connection is established between the remote system 20 and the RSC manager is informed (step 57). Accordingly, these steps correspond to step S2 in FIG. 4.

[0102] Here, the medical device accepts an access request that meets the configured at least one access criterion. Accordingly, when a request is received (step 58), it is accepted by the firewall (step 59) and forwarded to the RSC manager (step 60) on condition that it matches the configured IP settings and the enabled functions. These steps correspond to steps S3 and S4 in FIG. 4.

[0103] Thereafter, the RSC manager forwards or passes the request to the correct recipient (typically another process) within the medical device 10 (step 61). For example, the request is for one or more medical processes P MEDOr it is transferred to one of the other subsystems SS2 to SS4. This step corresponds to step S5a in FIG. 4.

[0104] The present invention has been described in connection with what is presently considered to be the most practical and preferred embodiments, but the present invention should not be limited to the disclosed embodiments. On the contrary, it is intended to cover various modifications and equivalent configurations included within the spirit and scope of the appended claims.

Claims

1. A method for remotely accessing a medical device (10) configured to perform a medical treatment, said medical device (10) being One or more medical processes (P involved in the operation of the medical device (10) ＭＥＤ ) and The one or more medical processes (P ＭＥＤ ) and a separate remote communication process (P ＣＯＭＭ ), wherein the remote communication process (P ＣＯＭＭ ) is configured to manage communication between the medical device (10) and one or more remote systems (20), the remote communication process (P ＣＯＭＭ ) and, controlled by a software system including The one or more medical processes (P ＭＥＤ ) have a higher priority than the remote communication process (P ＣＯＭＭ ), and the method is such that the remote communication process (P ＣＯＭＭ ) is - configuring at least one access criterion for remotely accessing said medical device (10) (S1); - establishing a secure connection between said medical device (10) and a remote system (20) (S2). - Receiving a request to access the one or more medical processes (P ＭＥＤ ) from the remote system (S3); - When the claim satisfies the at least one configured access criterion for remotely accessing the medical device (10), the one or more medical processes (PMED) have a higher priority than the remote communication process (PCOMM), and the claim is transferred to the one or more medical processes (P ＭＥＤ ), (S5a), a method.

2. The method according to claim 1, said method comprising - starting up said medical device (S0). All requests to access said one or more medical processes (P ＭＥＤ ) are blocked by said remote communication process (P ＣＯＭＭ ) during said startup (S0), method.

3. The method according to claim 1 or 2, wherein the method blocks a request to access the one or more medical processes (P ＭＥＤ ) that do not meet the at least one configured access criterion (S5b).

4. The method according to any one of claims 1 to 3, wherein said at least one access criterion includes - the sender or originator of said request being authenticated; - said request including a permitted request type; - said request relating to a permitted function; - the number of received requests per unit time not exceeding a threshold value. A method comprising at least one of the above.

5. The method according to any one of claims 1 to 4, wherein said at least one access criterion includes individual rules for different senders, request types, and / or functions.

6. The method according to any one of claims 1 to 5, wherein said configuring (S1) includes receiving configuration data from an operator and / or reading configuration data stored in said medical device (10), and configuring said at least one access criterion based on said received configuration data.

7. The method according to any one of claims 1 to 6, wherein said transferring (S5a) includes transferring said request using a protocol different from and / or independent of the protocol used for communication between said medical device (10) and a remote system (20).

8. The method according to any one of claims 1 to 7, wherein the medical device comprises a set of processors (161), and the one or more medical processes and the remote communication process (P ＣＯＭＭ ) are both executed by the same one or more processors of the set of processors (161).

9. The method according to any one of claims 1 to 8, wherein the remote communication process (P ＣＯＭＭ ), and the one or more medical processes (P ＭＥＤ ), being separate, means that they have separate memory spaces, separate process states, and / or communicate using inter-process communication.

10. The method according to any one of claims 1 to 9, wherein said request to access said one or more medical processes includes - a request to remotely control said medical device (10); - a request to update software within said medical device (10); - a request to set the time of said medical device (10); - a request to receive log data from said medical device (10); - a request to update the configuration of said medical device (10). - A request to update the credentials of the medical device (10), and A method including at least one of. **Claim 11** The method according to any one of claims 1 to 10, wherein a higher priority is given to the one or more medical processes (P ＭＥＤ ) than to the remote communication process (P ＣＯＭＭ ) with respect to the processing capacity of the medical device (10). **Claim 12** A medical device for performing a medical treatment, - A set of processors (161), and - A set of memory units (163) storing a software system for execution by the set of processors (161), and - A communication interface (162) enabling communication with one or more remote systems (20), The software system is configured to operate the medical device when executed by the set of processors (161), The software system involves one or more medical processes (P ＭＥＤ ) related to the operation of the medical device (10), and a remote communication process (P ＭＥＤ ) separate from the one or more medical processes (P ＣＯＭＭ ). The remote communication process (P ＣＯＭＭ ) is configured to manage communication between the medical device (10) and one or more remote systems (20), and the one or more medical processes (P ＭＥＤ ) have a higher priority than the remote communication process (P ＣＯＭＭ ). The software system, when executed by the set of processors (P1 to P4), executes the method according to any one of claims 1 to 11. A medical device. **Claim 13** A computer-readable medium including a software system for remotely accessing a medical device (10), the software system One or more medical processes (P) involved in the operation of the medical device (10) ＭＥＤ ), and The one or more medical processes (P ＭＥＤ ) are separate remote communication processes (P ＣＯＭＭ ), and the remote communication process (P ＣＯＭＭ ) is configured to manage communication between the medical device (10) and one or more remote systems (20), and includes a remote communication process (P ＣＯＭＭ ). The one or more medical processes (P ＭＥＤ ) have a higher priority than the remote communication process (P ＣＯＭＭ ), and the software system, when executed by a set of processors of the medical device (10), executes the method according to any one of claims 1 to 11, a computer-readable medium.

Images