Medical device, authentication server, and method for authorizing a user to access the device via a device user interface

Abstract

The present disclosure relates to a medical device, an authentication server (20), and a method for authorizing a user to access a medical device (10) via a device user interface. According to a first aspect, the present disclosure proposes a method for use in a medical device for authorizing a user to access the medical device via a device user interface. The method includes storing an authority public key of an authority asymmetric key pair associated with the authentication server (S0) and providing an authorization challenge to the user via the device user interface (S3) indicating a device public key of a temporary device asymmetric key pair generated at the medical device. The method further includes receiving from the user via the device user interface (S4) a response code including validity information encrypted using a shared key derivable from the authority private key of the authority asymmetric key pair and the provided device public key; and authorizing the user to access the medical device (S7) in response to the validity information being decrypted using the same shared key but derived at the medical device using the stored authority public key and the device private key of the temporary device asymmetric key pair. The present disclosure also relates to a computer program and a computer program product for implementing the method.

Description

[Technical field]

[0001] The present disclosure relates to a medical device, an authentication server, and a method for authorizing a user to access the medical device via a device user interface. The present disclosure also relates to a computer program and a computer program product for implementing the method. [Background technology]

[0002] Medical devices (hereafter simply referred to as devices) typically require that users, such as medical staff or technicians, be authenticated before they can access the device. If the medical device is online, i.e. in communication with a service system, the user can be granted access via the service system simply by logging in to the service system.

[0003] However, in some cases, a user needs to access a device that is offline from a service system. Today, offline devices typically use hard-coded passcodes (e.g., PINs, passwords, or keys) that can be entered via a user interface to authorize the user for access. This type of access authorization is no longer considered secure for several reasons.

[0004] For example, there is always the risk that passwords will be shared between users in an uncontrolled way. Also, passcode solutions require an additional production step, since each device needs to be pre-programmed with an individual passcode. Meanwhile, a lost PIN or password means no login at all. Thus, the infrastructure needs to maintain a secure database with passcodes for all devices, which demands administrative effort.

[0005] Additionally, anonymous passcodes do not provide auditing of who has accessed a particular device unless each passcode is used by a single user, but having multiple user identities and passcodes on each device requires a lot of maintenance when users change.

[0006] Another way to identify users is to use one-time passwords. However, one-time passwords require some kind of synchronization, either by one-time password order number or by time synchronization between the medical device and the password generator. However, typically, neither of these synchronization options are really manageable. For order-based one-time passwords without user ID, every user must communicate back to the password generator. This password is the last password used for each individual device, which is not feasible. Order-based one-time passwords with user IDs require maintenance of a user database on each offline device, as described above. Also, time-based one-time passwords are not feasible, since it cannot be guaranteed that the medical device clock is synchronized with the password generator time.

[0007] It should also be noted that even if the medical devices are connected to the service system, the technician may be outside the clinic and therefore not be able to be authenticated through the hospital's IT systems.

[0008] Thus, a need exists for an improved method of authorizing users to access equipment. Summary of the Invention

[0009] It is an object of the present disclosure to mitigate at least some of the drawbacks of existing solutions. It is a further object to provide a method for granting access to users in a secure manner, without the need to configure devices with individual information. In particular, it is an object to provide a solution that eliminates the need to configure individual passcodes on medical devices.

[0010] According to a first aspect, the present disclosure provides a method for use in a medical device, for authorizing a user to access the medical device via a device user interface. The method comprises storing an authority public key of an authority asymmetric key pair associated with an authentication server, and providing an authorization challenge to the user via the device user interface, indicating a device public key of a temporary device asymmetric key pair generated at the medical device. The method further comprises receiving from the user via the device user interface a response code including validity information encrypted using a shared key derivable from the authority private key of the authority asymmetric key pair and the provided device public key, and authorizing the user to access the medical device depending on the validity information being valid, the validity information decrypted using the same shared key, but derived at the medical device using the stored authority public key and the device private key of the temporary device asymmetric key pair. The proposed method allows to authorize a user to access an offline user device via a user interface without using a pre-configured passcode. In practice, this means that any user authorized by the authentication server may obtain a passcode from the authentication server and thereby access the medical device. It is therefore the authentication server that controls who is authorized to access the medical devices. By using one public key common to all devices, the individualization step in production may be eliminated. The method also eliminates the need for a database of private or symmetric keys per device and all the problems that may arise when replacing the hardware in the device and thereby replacing a new individual key. Finally, the method does not require that the clocks of the medical devices and the authentication server be synchronized.

[0011] In some embodiments, the user interface is a human-machine interface or a machine-machine interface configured to communicate with a user device of a user, such that the user may communicate the challenge and response manually or via a user device such as a wristband, a smartphone, or a portable data storage device such as a USB stick.

[0012] In some embodiments, authorizing includes authorizing different levels of access to the user due to information contained in the response code. Thus, one single method may be used for different types of users that would normally require different passcodes. Instead, the level of access is handled by the authentication server. In some embodiments, authorizing includes authorizing the user for at least one of authorizing a predetermined access to one or more sessions, unlocking the medical device for a specific use, and authorizing temporary non-routine use.

[0013] In some embodiments, authorizing includes authorizing access for a predefined period of time. Thus, authorization of access to a device may be limited to one or a few uses. Additionally, it may be limited in terms of time.

[0014] In some embodiments, the method includes receiving a user input that initiates authorization of access to the user. Thus, authentication may be initiated by, for example, a user pressing a button on the medical device.

[0015] In some embodiments, the method includes revoking the temporary device asymmetric key pair, which ensures that the temporary key is not valid after a single use or after a predefined time period. Therefore, for the next authorization, a new temporary device asymmetric key pair must be created, which increases security.

[0016] In some embodiments, the method includes the medical device being offline from the authentication server, and thus the method may also be used with offline medical devices.

[0017] According to a second aspect, the present disclosure relates to a method for use in an authentication server for authorizing a user to access a medical device via a server user interface. The method comprises storing an authority private key of an authority asymmetric key pair associated with the authentication server, authenticating the user, receiving an authorization challenge from the user via the server user interface indicating a device public key of a temporary device asymmetric key pair associated with the medical device, and providing a response code to the user via the server user interface, the response code including validity information encrypted using a shared key, the shared key being derived in the authentication server using the stored authority private key and the device public key. The method allows creating a response code that may be used to unlock the medical device based on the authentication of the user in the authentication server. Hence, all user authentication may be processed in one place, i.e. in the authentication server. And the authentication server acts on behalf of the user when access to the medical device is requested. In other words, the proposed method allows individual authentication for each user logged in the central system (i.e. cannot be cleared in the medical device), independent of the network infrastructure.

[0018] In practice, this means that once a user has been added to the authentication server, he may be granted access to any medical device controlled by the authentication server, i.e. all medical devices that store the authority public key of the authority asymmetric key pair and are configured to perform the method according to the first aspect. The method allows the remote authentication server to manage users, authorizations and deauthorizations, e.g. in case of staff changes. Changes are made immediately and do not require maintenance of individual devices.

[0019] In some embodiments, the server interface is a human-machine interface or a machine-machine interface configured to communicate with a user device of a user, such that the user may exchange challenges and responses manually or via a user device such as a wristband or a smartphone.

[0020] In some embodiments, determining includes determining the response code based on at least one of the user's authorization level, a time parameter, and the user's location. Thus, the authentication server may select which type of access to allow based on different parameters. For example, medical staff and technicians may be given different types of access. Also, some users may only be allowed to access medical equipment at certain times or in certain locations.

[0021] In some embodiments, the method includes logging information related to the authentication: since the authentication server knows which medical device access is granted to which user and when, it can generate a log of all accesses provided, which can be useful in many situations.

[0022] In some embodiments, the authority and device asymmetric key pairs are generated such that the private key of one asymmetric key pair, when used with the public key of the other asymmetric key pair, derives the same shared key as the other way around. In some embodiments, the shared key is derived using a Diffie-Hellman function. In some embodiments, the authority and device asymmetric key pairs are generated using Elliptic Curve Cryptography (ECC) or Rivest-Shamir-Adelman (RSA).

[0023] In some embodiments, the validity information includes at least one of a device identifier of the medical device, an address of the medical device, a predefined data sequence, and a data sequence determined using a predefined rule. Therefore, in practice, any "character string" known by the medical device may be used. In some embodiments, the validity information includes a control sum. Using a control sum, and therefore a checksum, may be useful when the response code is entered manually, since it is typically short.

[0024] According to a third aspect, the present disclosure relates to a corresponding medical device comprising a device user interface and a control device. The control device is configured to store an authority public key of an authority asymmetric key pair associated with an authentication server and to provide an authorization challenge to a user via the device user interface indicating a device public key of a temporary device asymmetric key pair generated in the medical device. The control device is further configured to receive from the user via the device user interface a response code including validity information encrypted using a shared key. The shared key is derivable from an authority private key of the authority asymmetric key pair and the provided device public key. The control device is further configured to authorize the user to access the medical device in response to the validity information being decrypted using the same shared key but derived in the medical device using the stored authority public key and the device private key of the temporary device asymmetric key pair.

[0025] According to a fourth aspect, the present disclosure relates to a corresponding authentication server comprising a server user interface. The authentication server is configured to store an authority private key of an authority asymmetric key pair associated with the authentication server and to authenticate a user. Furthermore, the authentication server is configured to receive an authorization challenge from the user via the server user interface, the authorization challenge indicating a device public key of a temporary device asymmetric key pair associated with the medical device. The authentication server is further configured to provide the user via the server user interface with a response code including validity information encrypted using a shared key, the shared key being derived in the authentication server using the stored authority private key and the device public key.

[0026] According to a fifth aspect, the present disclosure relates to a computer program comprising code means which, when run on a computer, causes the computer to carry out a method according to the first or second aspect.

[0027] According to a sixth aspect, the present disclosure relates to a computer program product comprising a computer readable medium and a computer program, said computer program being carried on the computer readable medium.

[0028] According to a seventh aspect, the present disclosure relates to a system comprising a medical device and an authentication server. [Brief description of the drawings]

[0029] Embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings, in which examples of embodiments of the present disclosure are shown. [Figure 1a] Describe a conceptual medical device. [Figure 1b] The control arrangement of the medical device of FIG. 1a will now be described in more detail. [Diagram 2] An authentication server is described. [Diagram 3] The signaling between the medical device and the authentication server when performing the methods of Figures 4 and 5 will now be described. [Figure 4]1 illustrates a flow chart of a method for use in a medical device. [Diagram 5] 1 illustrates a flow chart of a method for use in an authentication server. [Figure 6a] An exemplary medical device that may implement embodiments of the disclosed technology is described. [Figure 6b] Another exemplary medical device that may implement embodiments of the disclosed technology will now be described. [Figure 6c] Further exemplary medical devices that may implement embodiments of the disclosed technology are described below. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0030] The proposed solution involves two parties: the medical device and a response generator (also called the authentication server). The authentication server may for example be a remotely accessible system or it may be a secure server within the organization (e.g. in a hospital). The authentication server holds the authority private key (d A ) can be securely stored and the proposed challenge-response algorithm can be performed.

[0031] The proposed technique solves the above mentioned problems using asymmetric cryptography (also called "public key" cryptography), in particular a key exchange algorithm. Public key cryptography is based on the use of a key pair, where one key is used to encrypt data and the other is used to decrypt data. An encryption key cannot decrypt data, and a decryption key cannot encrypt data (in any meaningful way). If two parties each have one private key d and one public key Q, they can compute the same shared key K by combining their private key d with the other part of the public key Q.

[0032] As mentioned above, configuring each medical device with an individual encryption key requires an extra production step and an infrastructure to maintain a database of such encryption keys. Problems may also arise when changing the hardware of the device, such as replacing the electronic board on which the encryption keys are stored. Therefore, a solution is proposed that does not require individual keys to be stored in the medical device. Thus, in the proposed solution, the medical device does not contain any secrets that, if disclosed, would allow access to untrusted users.

[0033] The proposed solution uses two pairs of asymmetric keys, one temporary device asymmetric key pair and one authority asymmetric key pair. The authority asymmetric key pair is generated in advance. Every medical device produced by the manufacturer is authenticated with the authority public key Q of the authority asymmetric key pair. B The authority public key Q is pre-configured or pre-programmed with B does not need to be secret. However, the authority public key Q B must be stored in such a way that it cannot be modified, at least by untrusted parties.

[0034] The authority private key d of the authority asymmetric key pair B is securely stored in the authentication server. B is never made public. Furthermore, the agency private key d B The authority public key Q stored in the medical device is not changed, but the same key is used, for example, by the manufacturer, to enable access to all its medical devices. B The corresponding agency private key d Bis required to create the response code required to access the device. Thus, a user wanting to access a medical device needs to authenticate himself / herself with the authentication server in order to obtain a valid response code that may be used to access the medical device. This means that the medical device does not know which user has accessed the medical device. However, users can still be tracked at the authentication server by logging when and for which user and possibly for which medical device a response code was generated.

[0035] The temporary device asymmetric key pair is generated on the medical device every time a user wants to access the medical device. The temporary device asymmetric key pair is basically used to verify that the response code was issued for this particular medical device. The temporary device asymmetric key pair is generated using the same algorithm that was used to generate the authority asymmetric key pair. After one use, the temporary device asymmetric key pair is no longer valid. Therefore, a new temporary device asymmetric key pair must be generated.

[0036] The authority asymmetric key pair is used together with the temporary device asymmetric key pair to authorize access to the medical device, as described below, however the mathematical algorithms for asymmetric encryption and key exchange are also not part of this disclosure and the proposed solution does not depend on a particular algorithm, although for purely practical reasons some may be better suited for this purpose than others.

[0037] The following describes a medical device, an authentication server, and a method for authorizing a user to access the medical device via a device user interface. The proposed technology is applicable to any medical device where controlling user access is required or desirable. Medical devices include, but are not limited to, infusion pumps for fluids (e.g., nutritional fluids, intravenous therapy fluids, and oncology medications), water purification devices, and medical imaging devices.

[0038] FIG. 1a illustrates a conceptual medical device 10 in which the proposed technology may be implemented. The medical device 10 is for example a medical machine such as a dialysis machine. Alternatively, the medical device is a smaller medical device such as an infusion pump. The medical device 10 may comprise several individual devices connected to each other. The proposed technology may then be used to control user access to one or more of these devices. In principle, the medical device 10 may be any device intended for medical use.

[0039] The medical device 10 is configured to perform any medical procedure. The medical device 10 is not connected to a remote system that may grant access to the medical device 10. The medical device is therefore offline. In particular, this means that the authority private key d required to access the medical device 10 is not available. B The authorization system 20 (FIG. 2b) is offline from the authorization system 20 that holds the

[0040] In the simplified example illustrated, the medical device 10 comprises a device user interface 19 and a controller 16. The medical device also includes components (not shown) required to perform a medical procedure. The device user interface 19 allows a user to interact with and / or communicate information to and from the medical device. The device user interface 19 may include, for example, a display and buttons or a touch screen.

[0041] Figure 1b illustrates in more detail the controller 16 of any of the exemplary medical devices of Figure 1a. The controller 16 comprises a processor 161 and a memory 163. The processor 161 may be any commercially available processing device such as a CPU, DSP, microprocessor, FPGA, ASIC, or any other electronic programmable logic device, or combinations thereof.

[0042] The controller 16 may also include a communication interface 162 configured to enable communication with other devices or systems, such as a local server or a remote service system. 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 of Bluetooth, WiFi, Zigbee, Z-Wave, wireless universal serial bus ("USB"), infrared protocols, or any other suitable wireless communication technology. The short-range communication interface 162 is, for example, a Bluetooth chip configured to be controlled by the processor 161.

[0043] Memory 163 may include, but is not limited to, non-volatile or volatile memory, or a combination of ROM, PROM, EEPROM, flash memory, removable memory, RAM, DRAM, SRAM, cache memory, hard drives, storage media, etc. Memory 163 stores software code for execution by processor 161. The software code is configured to control medical device 10, for example, to perform a medical procedure and to enable user access to the medical device.

[0044] The processor 161 and memory 163 are "discrete" in the sense that they are individually operable units, but they may or may not be located in any combination on a common substrate, such as an integrated circuit. For simplicity, the controller 16 of FIG. 2a is described as comprising only one processor 161 and memory 163. However, it should be understood that the controller 16 may comprise a collection of processors comprising one or more processors 161, and the memory 163 may be implemented by one or more memory devices.

[0045] The controller 16 is configured to control the operation of the medical device 10, for example to perform the intended medical procedure of the medical device 10. The controller 16 is also configured to control access to the medical device 10.

[0046] FIG. 2 illustrates an authentication server 20. The authentication server is a control device configured to authenticate a user for access to a medical device. The authentication server 20 may be located on-site or off-site. In some embodiments, the authentication server 20 is integrated into another system, such as a hospital IT system or a manufacturer service system. The authentication server 20 may be one physical device, such as a computer, or may be a computer system running on multiple physical computers, such as a computer cloud. In some embodiments, the authentication server 20 is a local server, for example, in the hospital where the medical device 10 is used. The authentication server 20 comprises a server user interface 25. The authentication server 20 comprises a processor 21, a communication interface 22, and a memory 23. The 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.

[0047] The processor 21 and memory 23 are "discrete" in the sense that they are individually operable units, but they may or may not be located in any combination on a common substrate, such as an integrated circuit. For simplicity, the authentication server 20 of FIG. 2b is described as comprising only one processor 21 and memory 23. However, it should be understood that the authentication server 20 may comprise a collection of processors comprising one or more processors 21, and the memory 23 may be implemented by one or more memory devices. The communication interface 22 is an interface that allows communication between the authentication server 20 and other devices, such as remote devices via the Internet.

[0048] A user may interact with the authentication server 20 via a server user interface 25. The server user interface 25 is configured to enable interaction between the authentication server 20 and a user. In some embodiments, the server user interface 25 comprises a software user interface, e.g., a web interface or an application programming interface (API). Thus, the server user interface 25 may be rendered from the authentication server 20 on an external device, such as an external display or a user device (e.g., a personal computer). The server interface 25 may even be generated on a remote (i.e., off-site) device that accesses the server user interface 25 via the communication interface 22. In some embodiments, the server user interface 25 is a graphical user interface that enables a user to interact with the authentication server 20 through graphical icons.

[0049] In some embodiments, the server user interface 25 comprises a hardware interface that allows a user to interact with the authentication server 20 using physical components such as a keyboard, mouse and / or a display, e.g., a touch screen.

[0050] Now, with reference to figures 3 and 4, a method for use in a medical device 10 for authorizing a user 2 to access the medical device 10 via a device user interface will be described. Figure 3 illustrates the signaling between the medical device 10 and the authentication server 20 when performing the proposed method for authorizing a user 2 to access the medical device 10 via a device user interface. Figure 4 illustrates a flow chart of method steps performed in the medical device 10. The method for use in the medical device 10 means that the method steps of the method are performed by one or more components in the medical device 10, for example the control device 16. The method may be implemented as program code and stored in the memory 163 of the medical device 10. The method steps may be defined in a computer program comprising instructions for causing the control device 16 to perform the method when the program is executed by a computer, for example the control device 16.

[0051] The method may be performed whenever a user wishes to access the medical device 10 via the device user interface 19. Typically, this is the case when the medical device 10 is not connected to the Internet, or at least not connected to a service system that may automatically grant access to the user. In other words, in some embodiments, the medical device 10 is offline from the authentication server 20. Therefore, access needs to be provided using the device user interface 19. The medical device may have different types of device user interfaces 19, as described above. In some embodiments, the device user interface 19 is a human-machine interface. A human-machine interface is an interface that allows user actions to be translated as signals for a machine and for the machine to provide the requested results to the user. A human-machine interface may include, for example, buttons, one or more displays, a microphone, a speaker, etc.

[0052] In some embodiments, the appliance user interface 19 is a machine-machine interface configured to communicate with a user device of a user. The user device is for example a smartphone or a wearable device. The user device may for example be configured to read optical or radio signals. For example, the user device may be configured to read a sequence of symbols or a QR code. In some embodiments, the user device is a portable data storage, such as a USB stick. Hence, the user may read data from the appliance user interface 19 to the portable data storage and then transfer it further to the server user interface 25.

[0053] As mentioned above, a prerequisite for the proposed solution is that the medical device 10 has access to the authority public key Q of the authority asymmetric key pair associated with the authentication server 20. B The authority asymmetric key pair is pre-generated in the authentication server 20 using a pre-defined algorithm. There are many algorithms that may be used to generate the key pair. Some exemplary algorithms are Elliptic Curve Cryptography (ECC) or Rivest-Shamir-Adelman (RSA).

[0054] Authority public key Q B may be configured (i.e., stored) in the medical device 10 during manufacture of the medical device 10 or may be included in the software of the medical device 10. In other words, the method involves obtaining the authority public key Q of the authority asymmetric key pair associated with the authentication server 20. B The organization public key Q is stored in the database S0. B The authority public key Q must be stored in such a way that it cannot be changed or replaced. This can be done by any known common storage method, for example in software. B This can be done by hard-coding the authority public key Q, storing it in read-only memory (ROM), or storing it in a file in an internal file system that is inaccessible (or at least non-writable).B is any component that is difficult to replace and may be stored in a location where it cannot be replaced.

[0055] The authorization of access is initiated, for example, when a user requests access to the medical device via the device user interface 19. This is done, for example, by pressing a button or icon on the display 12 of the medical device 10. In other words, in some embodiments, the method includes receiving S1 a user input that initiates the authorization of access to the user 2. Alternatively, the authorization of access is initiated automatically, for example on start-up.

[0056] In response to user input or at automated start-up, a temporary key pair is generated S2 at the medical device 10 using the same algorithm that generated the authority asymmetric key pair. Thus, the method includes generating a device public key Q A and device private key d A The agency asymmetric key pair and the device asymmetric key pair are generated such that the private key d of one of the asymmetric key pairs is used with the public key Q of the other asymmetric key pair to derive the same shared key as vice versa.

[0057] After the temporary device asymmetric key pair is generated, an authentication challenge is presented to the user. The challenge is generated when the authentication server 20 verifies the device public key Q A In some embodiments, the challenge includes information that allows the device public key Q to be obtained. A The device public key Q A identifies the authorization session and allows to verify that the response code is intended for a particular challenge. The challenge may also include further information such as a device identification, e.g., a device identifier I or address, that allows the authentication server 20 to identify the medical device 10. For example, the device public key Q Ais presented to the user along with a device identifier, e.g., a serial number or a Media Access Control (MAC) address. This information is referred to as the "challenge" in the following. The presentation may be on-screen, human readable, e.g., a sequence of symbols, or machine readable, e.g., a QR code or a radio signal. The challenge may be relatively short by using an efficient public key cryptography algorithm such as Elliptic Curve Cryptography (ECC). An ECC-160 key is 20 bytes that can be presented in 25 printable characters.

[0058] For example, if the device ID is "123456" and the device public key is "36FD A6A2 13DC 2754", then the challenge presented to the user may be "12345636FDA6A213DC2754". In other words, the method involves obtaining the device public key Q of the temporary device asymmetric key pair generated in the medical device 10. A , and providing S3, via the device user interface, to User 2, an authorization challenge indicating A Any other data in the challenge other than the device public key Q A It may be encrypted with a shared key K which may be derived by the medical device 1 in response to receiving the

[0059] When the user is challenged, the user receives the authority private key d BTo do this, the user authenticates himself / herself to the authentication server 20 S21. This may be done directly via the server user interface 25 or via a person known by the user. In the authentication server 20, the user identity and access level are checked. The user then forwards a challenge to the authentication server 20, which receives the challenge S22. For example, the user reads the challenge presented on the display of the medical device and types it into the server user interface 25. Alternatively, the user forwards the challenge using a user device such as a smartphone or a USB stick. The challenge is generated using the device public key Q A The device public key Q A is the system private key d B is used to encrypt the response code. A ,d B ) which is returned to the user. Here, K(Q A ,d B ) is a function f(Q A ,d B ) by the authentication server 20. In some embodiments, the shared key K(Q A ,d B ) is derived using the Diffie-Hellman function.

[0060] Therefore, the authentication server 20 analyzes the challenge and derives the shared key K(Q A ,d B ) is calculated (i.e., generated S23). After that, the authentication server 20 calculates (i.e., determines S24) a response code and transmits the response code to the shared key K(Q A ,d B ) S25. The response code includes validity information. The validity information is information known to the medical device 10 and is used to encrypt the validity information S25 with the correct shared key K(Q A ,d B) was used. The response code is then presented to the user via the server user interface 25 (i.e., provided S26). The operations performed by the authentication server 20 to generate a valid response code are further described in connection with FIG. 5 below.

[0061] The user then enters the response code via the device user interface 19 of the medical device 10. In other words, the method for use in the medical device 10 involves using the authority private key d of the authority asymmetric key pair. B and the provided device public key Q A A shared key K(Q A ,d B ) from the user 2 via the equipment user interface 19.

[0062] Shared key K(Q A ,d B ) is the agency private key d B and the device public key Q indicated by the challenge A The validity information may be derived only by the response generator that has access to the shared key K(Q). The validity information is pre-agreed data. Therefore, the medical device 10 knows what validity information can be expected. A ,d B ) to decrypt the response code (or part of the response code), if the pre-agreed validity information is obtained, this guarantees beyond a reasonable doubt that the response code originated from a trusted response generator, i.e., the authentication server 20, and is intended for the particular challenge.

[0063] In some embodiments, the validity information includes a device identifier I of the medical device 1 provided in the challenge, such as a serial number of the medical device 10. In some embodiments, the validity information includes an address of the medical device 1 provided in the challenge, such as a MAC address of the medical device 10. In some embodiments, the validity information includes a predefined data sequence, such as "BX" or any pre-agreed text string.

[0064] In some embodiments, the validity information includes a data sequence determined using predefined rules. The data sequence may be, for example, a hash or control code calculated from information included in the challenge. For example, the response code may be a cyclic redundancy check (CRC) of the challenge or a part of the challenge. The response need not be longer than the original message because it is encrypted with a symmetric encryption scheme. The length of the data in a challenge-response transaction is important in case a user has to manually transfer the message.

[0065] Thus, the medical device 10 uses its temporary device private key d A , the stored authority public key Q of the authentication server 20 (i.e., the response generator) B , and generates the same shared key K(Q B ,d A ) and decrypt the response code, or at least the encrypted validity information, S6. Here, K(Q B ,d A ) is the function g(Q B ,d A ) is used to calculate the shared key on the medical device.

[0066] Therefore, the same shared key can be expressed as a function g(Q B ,d A ) or function f(Q A ,d B ) The shared key K may then be calculated using K = g(Q B ,d A )=f(QA ,d B ) In other words, the method may be expressed as: B and the generated device private key d A and the same shared key K(Q B ,d A It should be noted that the deriving S5 may already be performed earlier, for example immediately after generating S2 the temporary device asymmetric key pair. In that case, the shared key is the device public key D , which the authorization server 20 needs to derive the shared key. A Alternatively, the shared key may be used to encrypt any information included in the challenge. In some embodiments, the method also includes using the same derived shared key to decrypt S6 the validity information included in the response code.

[0067] If the validity information is valid, the user is granted access to the medical device 10. In some exemplary embodiments, the medical device 10 verifies the response code by decrypting the validity information and comparing the decrypted validity information with pre-agreed validity information that is stored in the medical device 10 or, alternatively, that the medical device 10 knows how to calculate. If the response code is valid, i.e., the decrypted validity information is the same or equal to the pre-agreed validity information, access is granted. In other words, the method involves multiple authentication methods using the same shared key K(Q B ,d A ), but the stored authority public key Q B and the device private key d of the temporary device asymmetric key pair A and granting the user 2 access to the medical device 10 in response to the validity information being valid, the validity information being decrypted using the shared key derived at the medical device 10 using the shared key.

[0068] The response code may include additional information, such as the authorization level of the user with the medical device 10. For example, medical staff may have one authorization level required to have the medical device 10 perform a medical procedure. However, a technician may not be authorized to have the medical device 10 perform a medical procedure. However, the technician may be authorized to operate the medical device 10 in a test mode, update software, enter a service mode or a privileged mode, etc. Thus, the response code may include additional information indicating which functions the user may access. In other words, in some embodiments, the authorizing S7 includes authorizing different levels of access to the user 2 depending on the information included in the response code. In some embodiments, the authorizing includes authorizing the user 2 a particular access level to one or more sessions, a session being, for example, a therapy session or a service session. Depending on the access level (e.g., as defined by the response code), the user may then perform predefined actions, such as adjusting clinical limits, adjusting default values, adjusting therapy settings for a session, and initiating a medical procedure.

[0069] In some embodiments, authorizing includes authorizing user 2 to authorize temporary non-routine use. Non-routine use includes, for example, running a session outside normal limits, for example turning off certain monitoring or safety systems. Another example of non-routine use is installing specialized software, for example for non-clinical demonstrations or troubleshooting.

[0070] In some embodiments, authorizing includes unlocking the medical device for a predetermined use. In other words, the response code may also include other information, such as commercial information, that may unlock predetermined functions within the medical device. In this manner, the authorization server may control the medical device 10. One particular example is that the medical device may be unlocked for clinical use if it was previously blocked.

[0071] All the above examples are essentially based on the proposed method allowing to transmit authenticated data from an authentication server to the medical device 10.

[0072] The response code may even convey "institutionally authorized" data to the medical device 10, i.e., data that an unauthorised user is authorised to enter into the device. This may be, for example, authorization for clinical use (e.g. if the device also has non-clinical software, e.g. for demonstration), extended use (e.g. neonatal use where the medical device is not approved in its basic configuration), or the purchase of some commercial option. This allows important data to be controlled centrally within an organisation, which is more secure than delegating control to individual users.

[0073] As mentioned above, the proposed method is typically intended for one-time use. Therefore, the response code may only be valid for a predefined period of time. The time may be predefined or may be defined by information contained in the response code. The period may be an absolute quantity. For example, it may start at the time S3 when the challenge is provided or when the response code is first entered. Alternatively, the period may be determined relative to the time at the medical device 10, which requires that the clocks of the medical device 10 and the authentication server are synchronized. In other words, in some embodiments, authorizing S7 comprises authorizing access for a predefined period of time. However, it must be noted that the method does not require synchronized clocks.

[0074] To enhance security, the temporary device asymmetric key pair should be valid for only one authentication. Therefore, after granting access to the user, the temporary device asymmetric key pair should be revoked. Alternatively, this may be done after a pre-determined period of time. In other words, in some embodiments, the method includes revoking S8 the temporary device asymmetric key pair. For example, the temporary key pair is deleted or revoked in any other way.

[0075] Fig. 5 illustrates a flow chart of a corresponding method for use in the authentication server 20. That the method is for use in the authentication server 20 means that the method steps of the method are executed by one or more components in the authentication server 20, for example by the processor 21. The method may be implemented as program code stored in the memory 23 of the authentication server 20. The method steps may be defined in a computer program, which comprises instructions that cause a computer to execute the method when the program is executed by a computer, for example by the processor 21.

[0076] The method is typically executed when a user wishing to access the medical device 10 is challenged by the medical device 10 and requires a valid response code to access the medical device 10. This may be, for example, when the medical device 10 is not connected to the Internet, or at least not connected to any service system that may automatically grant access. In other words, in some embodiments, the medical device 10 is offline from the authentication server 20.

[0077] The method requires that a user interacts with the authentication server 20 using the server user interface 25. It must be noted that this does not necessarily have to be the same person who is trying to access the medical device 10. In principle, a technician wishing to access the medical device 10 may place a telephone call to a person with access to the server user interface 25 of the authentication server 20. In such a situation, a challenge and response code may be communicated via telephone. Of course, this requires that the person with access to the authentication server 20 recognizes the technician and can ensure that the person is trusted.

[0078] As mentioned above, the proposed solution is that the authentication server 20 stores the authority private key d B In other words, the method is based on the concept of storing the authority private key d of the authority asymmetric key pair associated with the authentication server 20. B The authority public key Q is stored in the database S20. B Since the authentication server 20 may also be required to establish secure communications with other devices, it may not store the authority public key Q. B However, this is not required to perform the proposed method.

[0079] The challenged user must first log in to the authentication server 20. In other words, the user must prove his identity. This can be done in any conventional way, like using credentials or using more secure authentication methods like digital certificates. However, since the authentication server 20 is part of another system, like for example a hospital IT system or a manufacturer service system, this type of functionality is typically already in place and must be updated somehow with recent changes regarding active users. In other words, the method further comprises authenticating 21 the user 2. The authentication is typically done via a server user interface 25, which may be a human-machine interface, or a machine-machine interface configured to communicate with the user's user device.

[0080] The method is typically initiated by the user. The user may have to select a particular function, such as for example "Access Device" or the like. The user is then requested to enter a challenge obtained from the medical device 10. In other words, the method begins with the authentication server receiving the device public key Q of a temporary device asymmetric key pair associated with the medical device 10. A The method includes receiving an authorization challenge from user 2 via server user interface 25, the authorization challenge indicating

[0081] The authorization server 20 generates a response code based on the challenge and the authentication of the user. In other words, the method B ,d A ) to the user 2 via the server user interface 25, the response code including the validity information encrypted using the stored authority private key d B and the device public key Q A and the response code is derived in the authentication server 20 using the response code. The response code may be used to access, i.e. unlock, the medical device 10 that generated the challenge, as described above. This will be explained in more detail below.

[0082] The received challenge is sent to the stored authority private key d B The device public key Q is combined with the shared key K to encrypt the message, the authentication code, returned to the user. A In other words, the authentication server 20 includes (i.e., has) a stored authority private key d B and the received device public key Q A and generate a shared key S23. The authentication server 20 also determines a response code S24, which includes validity information, for example based on the authentication and possibly other parameters included in the challenge. These other parameters are for example the device identifier I of the medical device 1, the address of the medical device 1, or some other information.

[0083] The authentication server 20 typically has a lot of data about the user and the various medical devices. Therefore, the medical device 10 may determine whether the user is trusted to access a particular medical device 10, for example, identified by the device identifier I of 1 or the address included in the challenge. Also, in some embodiments, different levels of access are determined based on the authenticated user's access, the time of day. In some embodiments, the authorization server 20 knows the location of the user. In that case, access may be granted only if the location of the user corresponds to the location of the medical device 10 that the user wants to access. In other words, in some embodiments, determining S24 includes determining a response code based on the device identifier I of the medical device 1, the address of the medical device 1, the authorization level of the user 2, a time parameter, and / or the location of the user 2.

[0084] The authentication server 20 creates a response code, which includes the pre-agreed verification server and possibly some additional information. As mentioned above, the information that allows the medical device 10 to verify the authentication validity information may be any information included in the challenge, such as the device identifier I of the medical device 1 or the address of the medical device. Alternatively, it may be any pre-agreed data, or data calculated by pre-agreed rules. In addition to the validity information, other data may be added to the response code. The other data may inform the medical device about the user's identity or access. For example, the other data may specify an access level, or may even include commercial information that unlocks certain functions in the medical device 10. In one exemplary embodiment, information that unlocks the medical device for a certain medical use may be sent.

[0085] After that, the authentication server 20 transmits the generated shared key K(Q A ,d B ) to decrypt S25 the determined response code (or at least the validity information) and display the encrypted response code on the server user interface 25. In some embodiments, the shared key K(Q A ,d B ) is a symmetric cryptography method, so the response code does not need to be longer than the original message, e.g., the validity information. The length of the data in a challenge-response transaction is important if users have to transfer messages manually.

[0086] Since the medical device 10 does not know the identity of the user, the authentication server must keep track of the user. Therefore, a record of all generated response codes should typically be stored in the authentication server 20 along with a timestamp and user identification information. In this way, it is very easy to find out which user accessed a particular medical device 10 and when. In other words, in some embodiments, the method includes logging S27 information related to the authentication.

[0087] In the above protocol, only one key needs to be protected: the stored authority private key d B The public key is not sufficient to generate a response code, only the device public key d A The authority public key Q only persists temporarily within the medical device 10, and a new device asymmetric key pair is generated for each transaction. It is possible to disassemble one medical device 10, decompile its source code, and read all data in its internal storage without losing the authority public key Q. B , which is not sufficient to hack into another medical device 10, or even to hack into the same medical device 10 the next time authentication is performed.

[0088] Furthermore, the proposed method enables and permits the transfer of encrypted data from the device to the institution and vice versa, since the key pair can be used to transfer practically any information.

[0089] The present disclosure also relates to a corresponding control device 16 configured to carry out any of the aspects of the method (FIG. 4) described above. For example, the processor 161 of the control device 16 is configured to execute a computer program stored in the memory 163 to achieve this. Thus, the methods referred to herein are typically implemented as programs.

[0090] More specifically, the control unit 16 receives the authority public key Q of the authority asymmetric key pair associated with the authentication server 20. B and storing the device public key Q of the temporary device asymmetric key pair generated by the medical device 10. A The medical device is configured to cause the medical device 10 to provide an authorization challenge to the user 2 via the device user interface indicating the

[0091] The control unit 16 also receives the authority private key d of the authority asymmetric key pair. B and the provided device public key Q Aand receives from User 2 via the equipment user interface a response code including validity information encrypted using a shared key derivable from the same shared key but stored in the authority public key Q. B and the device private key d of the temporary device asymmetric key pair. A and is configured to grant access to the medical device 10 to the user 2 in response to the validity information being valid, the validity information being decrypted using the shared key derived in the medical device 10 using the shared key.

[0092] In some embodiments the user interface is a human-machine interface or a machine-machine interface configured to communicate with a user device of a user.

[0093] In some embodiments, the controller 16 is configured to grant different access levels to the user 2 depending on the information contained in the response code.

[0094] In some embodiments, the controller 16 is configured to grant access to the user 2 for at least one of granting predetermined access to one or more sessions, unlocking the medical device for a specific use, and granting temporary, non-routine use.

[0095] In some embodiments, the controller 16 is configured to grant access for a predetermined period of time.

[0096] In some embodiments, the controller 16 is configured to receive user input via the device user interface that initiates authorization of access to the user 2 .

[0097] In some embodiments, the controller 16 is configured to revoke S8 the temporary device asymmetric key pair.

[0098] In some embodiments, the medical device 10 is offline from the authentication server 20 .

[0099] The present disclosure also relates to an authentication server 20 configured to carry out all aspects of the method (FIG. 5) described above, for example, the processor 21 of the authentication server 20 configured to execute a computer program stored in a memory 23 to achieve this.

[0100] More specifically, the authentication server 20 stores the authority private key d of the authority asymmetric key pair associated with the authentication server 20. B The authentication server 20 is also configured to receive from the user 2 via the server user interface 25 a device public key Q of a temporary device asymmetric key pair associated with the medical device 10. A and providing a response code including validity information encrypted using a shared key to the user 2 via the server user interface 25, the shared key being stored in the authority private key d B and the device public key Q A and are derived in the authentication server 20 using

[0101] In some embodiments, the server interface is a human-machine interface or a machine-machine interface configured to communicate with a user device of a user.

[0102] In some embodiments, the authentication server is configured to determine the response code based on at least one of the authorization level of the user 2, the time parameter, and the location of the user 2.

[0103] In some embodiments, the authentication server is configured to log information related to the authentication.

[0104] FIG. 6a illustrates a medical device 10, 10' in which the proposed technology may be implemented. The medical device 10, 10' may be involved in a medical procedure to perform extracorporeal blood treatment, for example as part of a renal replacement therapy such as hemodialysis, hemodiafiltration, hemofiltration or ultrafiltration. The medical device indicated at 10 is a blood treatment device, which comprises a blood withdrawal line 11A and a blood return line 11B for connection to the circulatory system of a subject 100, for example in a vascular access. As indicated by the arrows, the medical device 10 is operable to draw blood from the subject 100 (e.g. a human), to process the blood and to return the processed blood to the subject 100 in a controlled manner. The medical device indicated at 10' is operable to prepare fluids used by the blood treatment device 10 and comprises fluid lines 11 for supplying the fluids to the blood treatment device 10. In one example, the medical device 10' is a water preparation device, the fluid being purified water. For example, the water treatment device 10' may filter the incoming water by reverse osmosis, as known in the art.

[0105] In the simplified example shown, the medical device 10 comprises fluid lines 11 for connection to a subject 100, a device user interface 19, a controller 16, one or more actuators 17 for controlled delivery of medical fluid to the subject 100 via the fluid lines 11, and one or more sensors 18 for providing sensor data indicative of the infusion process performed by the infusion pump. The actuators 17 and sensors 18 may comprise internal components (shown in dashed lines) and / or external components of the medical device 10. The device user interface 19 comprises a display 12, control buttons 13 (one shown), indicator lamps 14, and a speaker 15.

[0106] The actuator 17 is configured, for example, to control valves, pumps and / or heaters used while performing a medical procedure, in other words, the actuator 17 is configured to control the medical procedure.

[0107] The controller 16 is configured to coordinate operation of the actuators 17 and sensors 18, and to obtain user input via the control buttons 13, to perform the intended medical procedure of the blood processing device, as well as to operate the display 12, indicator lights 14, and speaker 15 as necessary in connection with the medical procedure. For example, the display 12 may be operated to present instructions to a user of the medical device 10, the indicator lights 14 may be operated to indicate a status of the medical device, the speaker 15 may be operated to generate an alarm signal, etc.

[0108] The medical device 10 is not connected to any remote system. The medical device is therefore offline. In particular, it is offline from the authentication system 20 (Figure 2b).

[0109] Medical device 10' may have a similar collection of components as medical device 10, at the level of detail shown, and will not be described further. Medical device 10, 10' may include many more components than shown, which will not be described herein for the sake of brevity.

[0110] The medical device 10, 10' is involved in a medical procedure involving extracorporeal blood treatment. Therefore, due to patient security, it is very important that only trusted users are authorized to access the medical device 10, 10', as such access may jeopardize future procedures.

[0111] Figure 6b illustrates another exemplary medical device 10 operable to deliver dialysate to and subsequently remove dialysate from the peritoneal cavity of a subject 100 in a controlled manner, as indicated by the double-headed arrow. This medical procedure is commonly known as automated peritoneal dialysis, and the medical device 10 is often referred to as a "PD cycler." The medical device 10 of Figure 6b may have a similar (but typically reduced) collection of components, at the illustrated level of detail, as compared to the medical device 10 of Figure 6a.

[0112] FIG. 6c illustrates a further exemplary medical device 10 operable to deliver a medical fluid to the body of a subject 100, such as a human, in a controlled manner, as indicated by an arrow, for example to the circulatory system of the subject 100. The medical fluid may be any suitable liquid, including but not limited to drugs and / or nutrients. This type of medical device 10 is commonly known as an "infusion pump." The medical device 10 of FIG. 6c may have a similar collection of components as the medical device 10 of FIG. 6b, at the level of detail illustrated, and will not be described further. The medical device 10 of FIG. 6c may include more components than shown, which will not be described herein for the sake of brevity.

Claims

1. A method for authorizing a user (2) to access a medical device (10) that is offline from an authentication server (20) via a device interface, the method comprising the steps of: - the authority public key (Q) of the authority asymmetric key pair associated with said authentication server (20) B ) (S0); and Each time a user wants to access the medical device, the device public key (Q) of a temporary device asymmetric key pair generated on the medical device (10) is A providing (S3) an authorization challenge indicative of a medical device identification number (10) to the user (2) via the device interface, the authorization challenge including device identification information enabling the authentication server (20) to identify the medical device (10); - the authority private key of said authority asymmetric key pair (d B ), and the provided device public key (Q A receiving (S4) a response code from the user (2) via the device interface, the response code including validity information encrypted using a shared key derivable from - the same shared key, but with the stored authority public key (Q B ), and a device private key (d) of the temporary device asymmetric key pair. A and authorizing (S7) the user (2) to access the medical device (10) in response to the validity information being valid, the validity information being decrypted using a shared key derived in the medical device (10) using the shared key.

2. The method of claim 1 , wherein the equipment interface is a human-machine interface or a machine-machine interface configured to communicate with a user device of the user.

3. 3. The method of claim 1 or 2, wherein the authorizing (S7) comprises authorizing different levels of access to the user (2) depending on information contained in the response code.

4. 4. The method according to claim 1, wherein the authorizing comprises authorizing the user (2) for at least one of authorizing predetermined access to one or more sessions, unlocking the medical device for a predetermined use, and authorizing temporary non-routine use.

5. 5. The method of any one of claims 1 to 4, wherein said authorizing (S7) comprises authorizing access for a predetermined period of time.

6. 6. The method according to any one of claims 1 to 5, comprising: - receiving (S1) a user input initiating the granting of access to said user (2).

7. 7. The method according to any one of claims 1 to 6, comprising: - destroying (S8) said temporary device asymmetric key pair.

8. A method for authorizing a user (2) to access a medical device (10) that is offline from an authentication server (20) via a server user interface (25), the method comprising the steps of: - the authority private key (d) of the authority asymmetric key pair associated with said authentication server (20) B ) (S20); and - authenticating (S21) said user (2); - a device public key (Q) of a temporary device asymmetric key pair associated with said medical device (10); A receiving (S22) from the user (2) via the server user interface (25) an authorization challenge that indicates a user's ID and is generated in the medical device (10) each time the user wishes to access the medical device, the authorization challenge including device identification information that enables the authentication server (20) to identify the medical device (10); providing (S26) to the user (2) via the server user interface (25) a response code including validity information encrypted using a shared key, the shared key being the stored authority private key (d B ), and the device public key (Q A ) and deriving the authentication server (20) using

9. 9. The method of claim 8, wherein the server user interface is a human-machine interface or a machine-machine interface configured to communicate with a user device of the user.

10. 10. The method of claim 8 or 9, comprising determining (24) the response code based on at least one of an authorization level of the user (2), a time parameter, and a location of the user (2).

11. 11. The method according to any one of claims 8 to 10, comprising: - logging (S27) information related to said authentication.

12. 12. The method of claim 1, wherein the authority asymmetric key pair and the temporary device asymmetric key pair are generated such that a private key (p) of one of the authority asymmetric key pair and the temporary device asymmetric key pair is used with a public key (Q) of the other of the authority asymmetric key pair and the temporary device asymmetric key pair to derive the same shared key as in the opposite case.

13. 13. The method of any one of claims 1 to 12, wherein the shared key is derived using a Diffie-Hellman function.

14. 14. The method of any one of claims 1 to 13, wherein the authority asymmetric key pair and the ephemeral device asymmetric key pair are generated using Elliptic Curve Cryptography (ECC) or Rivest-Shamir-Adelman (RSA).

15. 15. The method according to any one of claims 1 to 14, wherein the validity information comprises at least one of a device identifier of the medical device (1), an address of the medical device (1), a predefined data sequence, and a data sequence determined using a predefined rule.

16. A medical device (10), comprising: an equipment interface (19), - to the authentication server (20), An authority public key (Q) of an authority asymmetric key pair associated with an authentication server (20) that is offline from the medical device (10) B ) and Each time a user wishes to access the medical device, the device public key (Q) of a temporary device asymmetric key pair generated on the medical device (10) is A providing the user (2) via the device interface with an authorization challenge indicative of a medical device identification (ID) that allows the authentication server (20) to identify the medical device (10); The authority private key of the authority asymmetric key pair (d B ), and the provided device public key (Q A receiving a response code from the user (2) via the device interface, the response code including validity information encrypted using a shared key derivable from the authentication key; The same shared key, but the stored authority public key (Q B ), and a device private key (d) of the temporary device asymmetric key pair. A ) and, in response to the validity information being valid, the validity information is decrypted using a shared key derived at the medical device using the shared key. and a control device configured to cause the medical device to:

17. 17. The medical device (10) of claim 16, wherein the device interface is a human-machine interface or a machine-machine interface configured to communicate with a user device of the user.

18. 18. The medical device (10) of claim 16 or 17, wherein the control device (16) is configured to grant different levels of access to the user (2) depending on information contained in the response code.

19. 19. The medical device (10) of claim 16, wherein the control device (16) is configured to grant access to the user (2) for at least one of granting predetermined access to one or more sessions, unlocking the medical device for a predetermined use, and granting temporary non-routine use.

20. 20. The medical device (10) of any one of claims 16 to 19, wherein the control device (16) is configured to grant access for a predetermined period of time.

21. 21. The medical device (10) according to any one of claims 16 to 20, wherein the control device (16) - a medical device (10) configured to receive, via said device interface, a user input initiating the authorization of access to said user (2).

22. 22. The medical device (10) according to any one of claims 16 to 21, wherein the control device (16) - a medical device (10), configured to revoke said temporary device asymmetric key pair.

23. An authentication server (20) having a server user interface (25), said authentication server (20) comprising: The authority private key (d) of the authority asymmetric key pair associated with the authentication server (20) B ) and - authenticating a user (2); A device public key (Q) of a temporary device asymmetric key pair associated with a medical device (10) that is offline from the authentication server (20). A receiving from the user (2) via the server user interface (25) an authorization challenge that is generated in the medical device (10) each time the user wishes to access the medical device (10), the authorization challenge including device identification information that enables the authentication server (20) to identify the medical device (10); Providing to the user (2) via the server user interface (25) a response code including validity information encrypted using a shared key, the shared key being the stored authority private key (d B ), and the device public key (Q A ) is derived in the authentication server (20) using An authentication server (20) configured to:

24. 24. The authentication server (20) of claim 23, wherein the server user interface is a human-machine interface or a machine-machine interface configured to communicate with a user device of the user.

25. 25. An authentication server (20) according to claim 23 or 24, wherein the authentication server (20) is configured to determine the response code based on at least one of an authorization level of the user (2), a time parameter, and a location of the user (2).

26. 26. The authentication server (20) of any one of claims 23 to 25, wherein the authentication server (20) is configured (S27) to log information related to the authentication.

27. A computer program comprising code means which, when run on a computer, causes said computer to carry out a method according to any one of claims 1 to 7 or 8 to 15.

28. 28. A computer readable medium having stored thereon the computer program of claim 27.

29. A system comprising a medical device (10) according to any one of claims 16 to 22 and an authentication server (20) according to any one of claims 23 to 26.

Images