Online authentication of medical devices

Abstract

A medical device includes a QR generator and a user access / activity log. The QR generator generates a QR code from at least a user name of a user and at least one OTP (one-time password) for the user, and enables the user to access the medical device when receiving the OTP from the user. The user sends the QR code to an online authorization server of the medical device for decryption when authenticating the user. Once the user is authenticated by the server, the log lists user activity. The server receives a QR code including at least encrypted text, the QR code including at least an OTP and a user identification, and decrypts the encrypted text using a private key associated with the medical device. The authorization server enables the user to log in for authentication and, if authenticated, displays the at least one OTP to the user.

Description

Technical Field

[0001] The present invention relates generally to user authentication, and in particular to user authentication on medical devices. Background Art

[0002] Many typical modern devices are connected to the Internet and allow users to log in to online user databases. This is true for most office computers, smart phones, smart TVs, etc., for example. However, there are other devices that may not be connected to the Internet, or if connected, it is impossible to access the database that can authenticate a specific user. For example, some hospitals are reluctant to connect their medical devices (such as, ultrasound machines, electrocardiographs, MRI (magnetic resonance imaging) machines, mechanical ventilators, robotic surgical systems, etc.) to the Internet to maintain the security of the device and patient confidentiality. Wherein, if such devices are connected to the Internet, they can be connected to the back of the firewall or connected to a database system containing some necessary users (for example, hospital personnel) but not containing the credentials of other users (for example, technicians or third-party personnel). For example, technicians or hospital users sent by medical device manufacturers may need to be authenticated for online user directories controlled by those entities or third parties, and are ideally authenticated in a user-friendly manner.

[0003] Siemens Healthcare GmbH's U.S. Patent No. 10,516,536, Gambro Lundia AB's PCT Publication No. WO2021 / 122440, and Hewlett-Packard's WO2020 / 176110 discuss authenticating technicians and / or users and generally follow Figure 1 The method generally shown in , to which reference is now made. A user 10 may request access to a medical device 12 at a hospital 14. In response, the medical device 12 displays a QR code on a screen 16.

[0004] The user 10 opens the website or application on a smartphone or another mobile device 18 and scans the QR code. The website or application can connect to the authorization server 20 via the Internet 19. The application or server 20 on the mobile device 18 sends a one-time password (OTP) to the user 10. The user 10 then enters the OTP into the medical device 12, thereby authorizing the user 10 to access. Summary of the invention

[0005] Therefore, according to a preferred embodiment of the present invention, a medical device is provided, which includes a QR generator and an authorizer and a user access / activity log. The QR generator and authorizer generate a QR code from at least a username of a current user and at least one randomly generated OTP (one-time password) for the current user, and enable the current user to access the medical device when at least one OTP is received by the current user. The current user sends the QR code to an online authorization server of the medical device to be decrypted when the current user is authenticated. Once the current user is authenticated by the online authorization server, the user access / activity log lists the current user's activities according to the username.

[0006] Furthermore, according to a preferred embodiment of the present invention, the QR generator and the authorizer include a public key encryptor for encrypting the information of the QR code.

[0007] Furthermore, according to a preferred embodiment of the present invention, the information includes a randomly generated OTP and the requested access level, and if the current user has permission for the requested access level, the authorization server displays the OTP.

[0008] Alternatively, according to a preferred embodiment of the present invention, the information includes multiple randomly generated OTPs, each OTP is used for a different access level, and the authorization server displays a selected one of the OTPs associated with the access level of the current user.

[0009] Furthermore, according to a preferred embodiment of the present invention, the information includes a user name and / or a deadline.

[0010] Alternatively, according to a preferred embodiment of the present invention, the information is appended as a query parameter to the URL (Uniform Resource Locator) of the authorization server.

[0011] Furthermore, according to a preferred embodiment of the present invention, the information includes a serial number or a key ID of the medical device.

[0012] According to a preferred embodiment of the present invention, an authorization server for a medical device is also provided. The server includes a QR code receiver, a QR code decryptor and a user authenticator. The QR code receiver receives a QR code from a mobile device of a user of the medical device. The QR code provides at least an encrypted text, wherein the encrypted text contains at least an OTP and a user identification. The QR code decryptor accesses a private key associated with the medical device and uses the associated private key to decrypt the public code encrypted portion of the QR code into at least a user name of the user and at least one OTP of the user. The user authenticator enables the user to log in to the authorization server for authentication, and if the user successfully logs in to the server, at least one OTP is displayed.

[0013] Furthermore, according to a preferred embodiment of the present invention, the server further comprises a permission database, which lists a plurality of users and their associated permission levels. The user authenticator selects an OTP from the at least one OTP according to the user's associated permission level.

[0014] According to a preferred embodiment of the present invention, the QR code includes a serial number or a key ID of the medical device, and a private key associated with the medical device is associated with the serial number or the key ID.

[0015] Finally, according to a preferred embodiment, a system includes a medical device and an authentication server configured as described above and herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. However, the organization and method of operation of the invention, together with objects, features, and advantages thereof, may be best understood by reference to the following detailed description when read in connection with the accompanying drawings, in which:

[0017] Figure 1 A schematic diagram of a user authentication method in the prior art.

[0018] Figure 2 Schematic diagram of a system for authenticating a user of a medical device using an online user database, constructed and operative in accordance with a preferred embodiment of the present invention.

[0019] Figure 3A and Figure 3B Reason Figure 2 Schematic representation of the screens produced by the system.

[0020] Figure 4 for Figure 2 Schematic diagram of the elements of the system.

[0021] Figure 5 Reason Figure 2 Flow chart of a method implemented by a system.

[0022] For simplicity and clarity of illustration, the elements shown in the figures may not be drawn to scale. For example, for clarity, the size of some of the elements may be exaggerated relative to other elements. In addition, where deemed appropriate, reference numerals may be repeated in the accompanying drawings to indicate corresponding or similar elements. DETAILED DESCRIPTION

[0023] In the following detailed description, many details are set forth to provide a comprehensive understanding of the present invention. However, it will be appreciated by those skilled in the art that the present invention may be practiced without these specific details. In other cases, well-known methods, procedures and components are not described in detail to avoid obscuring the present invention.

[0024] Applicants have recognized that a user-friendly way to authenticate a technician sent by a medical device manufacturer is to the medical device manufacturer's corporate login page, whereas a user-friendly way to authenticate a hospital user is to the hospital's corporate login page.

[0025] In addition, applicants have recognized the need for an audit trail of usernames on medical devices. Such an audit trail is not possible in the prior art where the medical device only knows whether the user is authorized but not who the user is (i.e., does not know the user's username or other identifying information).

[0026] Applicants have recognised that in order for user authentication on a device to be effective, some or all of the following elements should ideally be part of the process:

[0027] 1) User authentication for online user database;

[0028] 2) audit trails of medical devices that store usernames and user access levels;

[0029] 3) One-time password;

[0030] 4) a non-repudiable log of user activity stored on the medical device; and

[0031] 5) A process that maintains security even if a hacker gains access to the medical device.

[0032] See now Figure 2 , which shows an example system 50 for authenticating a user of a medical device 12 using an online user database. The system 50 includes a mobile device, here a smart phone 51 having an application 53 (e.g., a web browser or a stand-alone application) thereon that is capable of accessing the Internet, and a medical device 12 having a token generator and an authorizer 54. In this example, the token generator employed is a QR code generator. However, other embodiments of the present invention may employ alternative token generators to perform the functions described herein, either optically or non-optically. Alternatives include, but are not limited to, one-dimensional barcodes, SnapTags, near field communications (NFC), and Bluetooth. It should be understood that in the case of wireless methods such as NFC, as described with reference to the examples herein, the action of scanning the code will instead involve triggering communication between the mobile device and the medical device via an embedded circuit in a corresponding device associated with the relevant communication protocol (e.g., a near field communication chipset or integrated circuit configured to transmit and receive wireless communications). See also Figure 3A and Figure 3B , which shows the screen seen by the user 10 in this example.

[0033] In system 50, when user 10 wishes to log into medical device 52, user 10 must first log in, such as via medical device screen 58 ( Figure 2 ) on window 70( Figure 3A ) enters a username (such as his / her email address) into the QR generator and authorizer 54. It should be noted that the terms "token generator" (and its variety "QR generator") and authorizer used as nouns herein should be understood to refer to functional blocks of software code that have instructions that cause a processor of the medical device to perform an action associated with the noun, such as generating a QR code in the case of a QR generator. The QR generator 54 may then generate a QR code 72 ( Figure 3A ), and the resulting QR code 72 can be displayed on the screen 58. The user 10 can use the dedicated application 53 ( Figure 2 ) to scan the QR code, or alternatively, the QR code may contain a URL (Uniform Resource Locator) that forwards the user to an application on the cloud, for example, to an https address with some query parameters. In the latter case, the user can use any generic QR code scanner application on his / her smartphone. In both cases, the application enables communication to be established between the mobile device 51 and the authorization server 56 ( FIG. 3 ), which may cause the mobile device to display the enterprise login page 74 ( FIG. 14 ) of the hospital or manufacturer of the medical device 52. Figure 3B ). The user 10 may then log into the authorization server 56 via the login page 74. After successful authentication, the authentication server 56 may retrieve the access level of the user 10 from the online user database and may issue the user 10 a corresponding OTP (one-time password) 76 displayed on the smartphone 51, which the user 10 may then log into via the field 78 ( Figure 3A ) inputs the OTP to the mobile device. Based on the OTP 76, the QR generator and authorizer 54 ( Figure 2 ) can determine the permissions of the user 10 based on the entered OTP, and can grant access accordingly. The medical device 52 can then record all activities of the user 10 on the medical device 52 in the access / activity log 60.

[0034] It should be appreciated that the access / activity log 60 may associate access information with the username of each user 10 , and thus it will be possible to determine the actions performed by each user from only the information in the medical device 52 , without having to review the access log 22 of the authorization server 56 .

[0035] See now Figure 4 , which describes in detail the elements of the system 50, and see FIG. 6 , which describes in detail the method implemented by the system 50.

[0036] At the factory, each medical device 52 may be issued a private key / public key pair, which may be generated by any known asymmetric encryption algorithm (such as the RSA algorithm), wherein each medical device 52 may be accompanied by a stored in it marked 80 ( Figure 5 ) and serial number 81. The corresponding private key 83 is known only to the manufacturer's web server 82 and can be stored in a private key database 84, which lists the private keys 83 and the serial numbers 81 associated with them. The web server 82 can keep the private keys 83 secret and only use them as described below. For example, in order to keep the private keys secret, the web server 82 can store them in a hardware security module (HSM), such as an HSM device that complies with the Federal Information Processing Standards Publication 140-2 (FIPSPUB 140-2) Level 3 (or higher) standard. In this case, the private key database 84 can store a pointer to the HSM instead of the private keys themselves.

[0037] The web server 82, which may be the manufacturer's authorization server 56 and may be in contact with the hospital authorization server 56 for hospital users, may also have a permissions database 86 that may store the permissions 87 of current authorized users 10 and their associated username 85, which may be an email address or any other type of username.

[0038] The medical device 52 only knows its public key. Therefore, even if a hacker reverse-engineers all cryptographic keys and algorithms encoded in the medical device 52, she / he still cannot log in because she lacks the private key stored in the private key database 84 of the web server 82.

[0039] Figure 5 An embodiment is shown in which a different private key / public key pair is generated for each medical device 52. This ensures that if the private key of a single medical device is compromised, the other medical devices remain protected. In an alternative embodiment, as long as the private key 83 is well protected, preferably within a FIPS140-2 Level 3 (or higher) compliant HSM module, a single private key / public key pair can be used for all medical devices in the field. Under this premise, the user access / activity log 60 can still be non-repudiable and resistant to reverse engineering.

[0040] Each medical device 52 may include a QR generator and authorizer 54, a user access / activity log 60, and a log viewer (audit trail viewer) 90 for an administrator to view the log 60 to determine actions, the user names that performed those actions, and the timing of those actions. For example, an administrator may determine who logged in, who changed a calibration file, who deleted a study, and when those actions occurred.

[0041] The web server 82 may include a QR code receiver 79 for receiving the QR code from the smartphone application 53, a user authenticator 88 for authorizing the user and recording the authorization in the authorization log 22, and a QR code decryptor 89 for decrypting the QR code, as described below. The web server 82 may also include a log (audit trail) viewer 92 for an administrator to view information such as one-time password (OTP) requests, the timing of these requests, the serial number of the medical device making the request, and a list of allowed and denied requests.

[0042] In some embodiments, the QR code may include a URL address with query parameters, in which all required information may be embedded in the query parameters. In this case, the QR code receiver 79 may receive all information in the query parameters of the URL without the need to decode it.

[0043] When the user 10 requests to log in to the medical device 52, the QR generator and authorizer 54 may request his / her email address (or username), and optionally the access level he / she requested (step 100 of FIG. 6 ). In one embodiment, the user 10 may specify the access level he / she requested by selecting one of the options “technician”, “physician” or “nurse” in a multiple-select box in the graphical user interface of the medical device 52. By providing the user's access level, the medical device 52 may be able to implement different permission levels. For example, a technician may be allowed to perform calibration tasks, but may not have access to the patient's name, while the patient's name may be exposed to physicians and nurses, but they may not have access to perform technical maintenance tasks on the medical device 52.

[0044] In response, the QR generator 54 may generate (step 102) a hidden file in the volatile memory of the medical device 52 that stores at least the username and one or more randomly generated access-related OTPs. Optionally, the hidden file in the volatile memory may also contain a calculated expiration time.

[0045] For example, user 10 may have an email address of alice@jnj.com and may request to log in with a "technician" access level. In this example, the hidden file in the volatile memory of the medical device may look like the following:

[0046]

[0047] The QR generator and authorizer 54 may calculate the "expiration time" field as "now + some constant duration", such as "now + 15 minutes". The expiration time may enable the web server 52 to give a meaningful error message if the user attempts to obtain an OTP after the expiration time. Alternatively, the QR generator and authorizer 54 may be designed to reject the OTP after some predetermined amount of time. Thus, even in this alternative embodiment, the medical device 52 may be secure and resistant to replay attacks even without the expiration time in the hidden file.

[0048] The QR generator and authorizer 54 can generate an OTP by using a cryptographically strong random value generator function. The OTP can be composed of numbers and / or alphabetic characters and / or symbols. The OTP should preferably be short enough to be easily typed by the user 10, but longer and more complex OTPs are also possible.

[0049] The QR generator and authorizer 54 may encrypt the hidden file using its public key 80 (step 104) and may create a URL pointing to the web server 82, wherein the encrypted hidden file and optionally the serial number 81 of the medical device 52 are used as query parameters of the URL. The QR generator and authorizer 54 may encode the URL (step 106) in the QR code 72 ( Figure 4 A). Even if someone were to decode the QR code 72, the only information available would be the URL, which includes an encrypted version of the hidden file and optionally a serial number 81. The hidden file encrypted with the public key 80 can only be decrypted with the private key 83, which only the web server 82 has access to. Therefore, no one can discover the OTP encoded in the QR code 72. RSA, elliptic curve cryptography (ECC) or any other asymmetric algorithm can be used for key generation, data encryption and decryption.

[0050] The user may scan the QR code 72 using a universal camera application on the smartphone 51, and the universal camera application may forward the web browser in the smartphone 51 to the URL address encoded in the QR code 72, which may be hosted on the authentication web server 82, using specific query parameters. For example, the URL may look like the following:

[0051]

[0052] Alternatively, the QR code 72 may contain an encrypted version of the hidden file and optionally the serial number 81 of the medical device 52 in some other format (e.g., XML, JSON, or a proprietary file format). In this case, a dedicated application may be installed on the smartphone 51 to read the QR code 72 and forward it to the QR code receiver 79.

[0053] The authentication web server 82 can authenticate the user via the enterprise login page (step 108). For example, the web server 82 can determine whether the user is a technician employed by the medical device manufacturer or a hospital user by looking at the domain portion of the user's email address. Or, for example, if the requested access level is "technician", the web server 82 can assume that the user is a technician employed by the manufacturer, but if the requested access level is "physician" or "nurse", the web server 82 can assume that this is a hospital user. If the user is a technician employed by the medical device manufacturer, the web server 82 can forward him / her to the manufacturer's enterprise login page. If the user is a hospital user, the web server 82 can forward him / her to the hospital's enterprise login page. The web server 82 and the enterprise login page can communicate via an authentication protocol (such as OpenID, OAuth2.0 or SAML). After successful authentication, the enterprise login page can send the user back to the web server 82, and the web server 82 can send the encrypted hidden file and optionally the serial number of the medical device 52 to the QR code decryptor 89. The process continues to step 112.

[0054] In another embodiment, the user may scan the QR code 72 using a smartphone application developed specifically for the purposes of the present invention. In this case, the QR code 72 may include an encrypted hidden file and optionally the serial number of the medical device 52 in any format, such as XML, JSON, or a proprietary file format. In this case, the smartphone application may authenticate the user before or after scanning the QR code. Once the application successfully authenticates the user and the QR code 72 has been scanned, the process continues to step 112.

[0055] In step 112, the QR code decryptor 89 may access the private key database 84 to find the private key 83 associated with the sent serial number 81. Alternatively, if all medical devices are accompanied by the same private key / public key, the QR code decryptor 89 may use the constant private key 83 to decrypt the string in the QR code 72. If the private key 82 is stored in the HSM, the QR code decryptor 89 does not need to receive the private key 83; instead, the QR code decryptor may send the decryption command together with the hidden file to the HSM, and may receive the decrypted hidden file back from the HSM. Then, the QR code decryptor 89 may send the now decrypted hidden file to the user authenticator 88.

[0056] In step 114, the user authenticator 88 may verify that the "username" field in the decrypted string matches the actual username of the user who authenticated to the web server 82, for example, via the enterprise login page. And the user authenticator 88 may further verify via the permissions database 86 that the user 10 does have permission for the access level specified in the "Requested Access Level" field, and may verify based on its clock 24 (FIG. 3) that the "expiration time" field is in the future. If all conditions are met, the user authenticator 88 may store the associated OTP 76 ( Figure 4 B) Displayed as plain text (step 116) on the OTP page 77.

[0057] Upon seeing the displayed OTP 76, the user 10 may enter the OTP 76 into the QR generator and authorizer 54 on the medical device 52, and after checking the entered OTP against the OTP field in the hidden file, the QR generator and authorizer 54 may authorize the user 10 access to perform all tasks permitted in his / her access level.

[0058] It will be appreciated that the system 50 is resistant to replay attacks because each time a user requests an OTP, the associated QR code 72 will be different because the OTP encrypted in the QR code 72 is randomly generated and therefore the associated QR code 72 is different on each login attempt.

[0059] In an alternative embodiment, the same public key may be provided with each medical device 52. In this case, as mentioned above, a single private key 83 on the web server 82 is sufficient. However, when all medical devices 52 use the same public key 80, it is desirable to implement a method of replacing the key from time to time, such as after a few years, or when a new version of the medical device 52 is released to the market, or when the private key is compromised.

[0060] To enable replacement of keys, each private / public key pair can be assigned an ID. First, all medical devices 52 will be shipped with a public key 80 with ID=1. To signal to the web server 82 which public key 80 to use, the medical device 52 will encode the public key ID used for encryption in the QR code 72 (or in the query parameters of the URL encoded in the QR code), along with the encrypted hidden file.

[0061] A few years later, the manufacturer may begin deploying medical devices with a new public key of ID = 2. At this point in time, there will be two types of medical devices in the field. Those that still have the old public key of ID = 1, and those that have the new public key of ID = 2. In this case, the web server 82 will select the appropriate private key 83 for decryption based on the key ID that appears inside the QR code or inside the query parameters of the URL.

[0062] When the manufacturer decides to deactivate the old public key with ID=1, the private key with ID=1 will be removed from the database of the web server 82 or from the HSM. After this removal, the authentication function will not work for the medical device 52 with the old public key with ID=1.

[0063] It can be understood that the "key ID" in this embodiment is very similar to the "serial number" of the previous embodiment. Both the "key ID" and the "serial number" indicate which private key the QR code decryptor 89 uses to decrypt the QR code 72. In the embodiment with the "serial number", each individual medical device can have a separate private key / public key pair, while in the embodiment with the "key ID", each group of medical devices, such as all medical devices manufactured in the same year, can have one private key / public key. However, the use of the "key ID" and the "serial number" can be similar.

[0064] In the previous embodiment, the user needs to specify which access level she / he requests, in an alternative embodiment, the user 10 may receive the QR code 72 by simply writing his / her username, without specifying any desired access level. In this embodiment, the medical device 52 may create a different OTP for each possible access level in the system. In this embodiment, the hidden file may look like the following:

[0065]

[0066] In this embodiment, the QR generator and authorizer 54 may encrypt the version of the hidden file using the public key 80 , and the web server 82 may decrypt the encrypted file to its internal volatile memory using the private key 83 without disclosing anything to the user 10 .

[0067] Assuming that the web server 82 may have authenticated the user 10 via an enterprise login page or via some other method, and since the permission database 86 may list the permissions for the user 10, the web server 82 may select the relevant OTP (from the "Otp if technician", or "Otp if physician", or "Otp if nurse" field) based on the permission level of the user 10.

[0068] For example, if the user 10 is a physician, the web server 82 may only disclose the "Otp if physician" field to the user as an OTP. The user 10 may enter the OTP into the medical device 52, and thereby, the medical device 52 may automatically determine that the person is a physician. The medical device 52 may grant permission accordingly.

[0069] Unless otherwise specifically noted, it is apparent from the foregoing discussion that throughout the specification, discussions using terms such as "processing," "computing," "calculating," "determining," etc. refer to the actions and / or processes of any type of general purpose computer, such as a client / server system, a mobile computing device, a smart device, a cloud computing unit, or a similar electronic computing device, which operates and / or transforms data within a computing system's registers and / or memory into other data within the computing system's memory, registers, or other such information storage, transmission, or display device.

[0070] Embodiments of the present invention may include a device for performing the operations herein. The device may be specially constructed for the desired purpose, or the device may include a computing device or system generally having at least one processor and at least one memory, selectively activated or reconfigured by a computer program stored in a computer. When indicated by software, the resulting device may turn a general-purpose computer into an inventive element as discussed herein. Instructions may define inventive devices that operate with a desired computer platform. Such computer programs may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk, including optical disks, magneto-optical disks, read-only memories (ROMs), volatile memories, and non-volatile memories, random access memories (RAMs), electrically programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs), magnetic cards or optical cards, flash memory, disks on keys, or any other type of medium suitable for storing electronic instructions and capable of being connected to a computer system bus. Computer-readable storage media may also be implemented in cloud storage devices.

[0071] Some general purpose computers (including commercial mobile devices and smart phones) may include at least one communication element to enable communications with a data network and / or a mobile communications network.

[0072] The process and display provided herein are not inherently related to any particular computer or other device. Various general purpose systems can be used together with the program according to the teaching of this article, or it can be shown that it is convenient to construct a more specialized device to perform the desired method. The desired structure for various such systems will appear from the following description. In addition, embodiments of the present invention are not described with reference to any specific programming language. It should be understood that a variety of programming languages ​​can be used to implement the teachings of the present invention described herein.

[0073] While certain features of the invention have been shown and described herein, numerous modifications, substitutions, changes, and equivalents will now occur to those skilled in the art. It is therefore to be understood that the appended claims are intended to cover all such modifications and changes that fall within the true spirit of the invention.

Claims

1. A medical device, comprising a processor and a storage medium having instructions stored thereon, wherein the instructions, when executed by the processor, cause the medical device to: generating an authentication token based on at least a username of a current user and at least one randomly generated OTP (one-time password) for said current user; sending the authentication token to an online authorization server of the medical device for decryption when authenticating the current user; as well as enabling the current user to access the medical device upon receiving the at least one OTP from the current user, the OTP being generated by the authorization server, Once the current user is authenticated by the online authorization server, an access / activity log is generated to track and store the current user's activities according to the username.

2. The medical device according to claim 1, wherein: The generating the authentication token includes generating a QR code using a public key encryptor to encrypt information for the QR code.

3. The medical device according to claim 2, wherein: The information includes a randomly generated OTP and a requested access level, and the authorization server is used to display the OTP if the current user has permission for the requested access level.

4. The medical device according to claim 2, wherein: The information includes a plurality of randomly generated OTPs, each OTP being used for a different access level, and the authorization server being used to display a selected one of the OTPs that is associated with the access level of the current user.

5. The medical device according to claim 2, wherein: The information includes the user name.

6. The medical device according to claim 5, wherein: The information also includes a deadline.

7. The medical device according to claim 2, wherein: The information is appended as a query parameter to the URL (Uniform Resource Locator) of the authorization server.

8. The medical device according to claim 2, wherein: The information includes a serial number of the medical device.

9. The medical device according to claim 2, wherein: The information includes a key ID of the medical device.

10. An authorization server for a medical device, comprising a processor and a storage medium having instructions stored thereon, wherein when the instructions are executed by the processor, the medical device: receiving an authentication token from a mobile device for a user of the medical device, the authentication token providing at least encrypted text, wherein the encrypted text includes at least an OTP and a user identification; decrypting the authentication token to access a private key associated with the medical device, and decrypting the public code encrypted portion of the authentication token using the associated private key into at least a username of the user and at least one OTP for the user; and The user is enabled to log into the authorization server for authentication, and at least one OTP is displayed if the user successfully logs into the server.

11. The authorization server according to claim 10 further includes a permission database to list multiple users and their associated permission levels, and the user authenticator is used to select an OTP from the at least one OTP according to the associated permission level of the user.

12. The authorization server according to claim 10, wherein: The authentication token includes a serial number of the medical device, and the private key associated with the medical device is associated with the serial number.

13. The authorization server according to claim 10, wherein: The authentication token includes a public key ID of the medical device, and the private key associated with the medical device is associated with the public key ID.

14. The authorization server according to claim 10, wherein: The authentication token includes at least one of a QR code, a smart tag, or NFC communication.

15. A system comprising the medical device according to claim 1 and the authorization server according to claim 10.

16. The system of claim 15, wherein: The medical device generating the authentication token includes generating a QR code, and the QR calculator and authorizer include encrypting information for the QR code using a public key encryptor.

17. The system of claim 16, wherein: The information includes a randomly generated OTP and a requested access level, and the authorization server is used to display the OTP if the current user has permission for the requested access level.

18. The system of claim 15, wherein: The authorization server also includes a permission database to list multiple users and their associated permission levels, and the user authenticator is used to select an OTP from the at least one OTP according to the associated permission level of the user.

19. The system of claim 15, wherein: The authentication token includes a serial number of the medical device, and the private key associated with the medical device is associated with the serial number.

20. The system of claim 15, wherein: The authentication token includes a public key ID of the medical device, and the private key associated with the medical device is associated with the public key ID.

Images