Online authentication for medical devices

Abstract

The medical device includes a QR generator and a user access / activity log. The QR generator generates a QR code from at least a user's username and at least one OTP (one-time password) for the user, and allows the user access to the medical device upon receiving the OTP from the user. The user sends the QR code to the medical device's online authorization server for decryption upon user authentication. The log lists user activity once the user is authenticated by the server. The server receives the QR code, which includes at least encrypted text including at least the OTP and user identification information, and decrypts the encrypted text using a private key associated with the medical device. The authorization server allows the user to log in for authentication and, if authenticated, displays at least one OTP to the user.

Description

[Technical Field]

[0001] The present invention relates generally to user authentication, and more particularly to user authentication on medical devices. [Background technology]

[0002] Many typical modern devices are connected to the Internet and allow users to log in to an online database of users. This is true, for example, for most office computers, smartphones, smart TVs, etc. However, there are other devices that may not be connected to the Internet, or, if connected, may not have access to a database that can authenticate a particular user. For example, some hospitals are reluctant to connect medical devices such as ultrasound machines, electrocardiogram machines, MRI (magnetic resonance imaging) machines, ventilators, and robotic surgical systems to the Internet in order to maintain device security and patient confidentiality. If some such devices are connected to the Internet, they may be connected behind a firewall or to a database system that contains authentication information for some necessary users (e.g., hospital staff) but not for others, such as technicians or third-party personnel. For example, technicians dispatched by a medical device manufacturer or a hospital user may need to be authenticated against an online user directory controlled by those entities or a third party, ideally in a user-friendly manner.

[0003] U.S. Pat. No. 10,516,536 to Siemens Healthcare GmbH, PCT Publication No. 2021 / 122440 to Gambro Lundia AB, and PCT Publication No. 2020 / 176110 to Hewlett-Packard discuss authenticating technicians and / or users and generally follow the method generally illustrated in Figure 1, referenced herein. 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 a website or application on a smartphone or another mobile device 18 and scans the QR code. The website or application may connect to an authorization server 20 over the internet 19. Either the application on the mobile device 18 or the server 20 issues a one-time password (OTP) to the user 10. The user 10 then enters the OTP into the medical device 12, which grants access to the user 10. Summary of the Invention [Means for solving the problem]

[0005] Therefore, according to a preferred embodiment of the present invention, there is provided a medical device including a QR generator and authorizer and a user access / activity log. The QR generator and authorizer generates a QR code from at least a current user's username and at least one randomly generated OTP (One-Time Password) for the current user, and enables the current user to access the medical device upon receiving at least one OTP from the current user. The current user sends the QR code to the medical device's online authorization server for decryption upon authentication of the current user. The user access / activity log lists the current user's activities according to username once the current user is authenticated by the online authorization server.

[0006] Furthermore, in accordance with a preferred embodiment of the present invention, the QR generator and validator include a public key encryptor that encrypts information for the QR code.

[0007] Further, in accordance with a preferred embodiment of the present invention, the information includes a randomly generated OTP and the requested access level, and the authorization server displays the OTP if the current user is authorized for the requested access level.

[0008] Alternatively, in accordance with a preferred embodiment of the present invention, the information includes multiple randomly generated OTPs, each for a different access level, and the authorization server displays a selected one of the OTPs associated with the current user's access level.

[0009] Additionally, in accordance with a preferred embodiment of the present invention, the information includes a username and / or an expiration date.

[0010] Alternatively, in accordance with a preferred embodiment of the present invention, the information is appended as a query parameter to the URL (universal resource locator) of the authorization server.

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

[0012] According to a preferred embodiment of the present invention, there is also provided an authorization server for a medical device. The server includes a QR code receiver, a QR code decoder, 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 encrypted text, the encrypted text including at least an OTP and user identification information. The QR code decoder 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 the user's username and at least one OTP for the user. The user authenticator allows the user to log in to the authorization server for authentication and displays the at least one OTP if the user successfully logs in to the server.

[0013] Furthermore, in accordance with a preferred embodiment of the present invention, the server also includes an authorization database listing a number of users and their associated authorization levels, and the user authenticator selects one OTP from the at least one OTP according to the user's associated authorization level.

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

[0015] Finally, according to a preferred embodiment, the system comprises a medical device and an authentication server configured as described above and as described herein. [Brief explanation 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 this specification. The invention, however, both as to organization and method of operation, together with its objects, features, and advantages, may best be understood by reference to the following detailed description when read in connection with the accompanying drawings. [Figure 1]1 is a schematic illustration of a prior art user authentication method; [Figure 2] 1 is a schematic, illustrative diagram of a system for authentication of users of medical devices using an online database of users, constructed and operative in accordance with a preferred embodiment of the present invention; [Figure 3A] FIG. 3 is a schematic, illustrative view of a screen provided by the system of FIG. 2; [Figure 3B] FIG. 3 is a schematic, illustrative view of a screen provided by the system of FIG. 2; [Figure 4] FIG. 3 is a schematic, illustrative view of elements of the system of FIG. 2. [Figure 5] FIG. 3 is a flowchart illustrating operations implemented by the system of FIG. 2. For simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some elements may be exaggerated relative to other elements for clarity. Furthermore, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or similar elements. DETAILED DESCRIPTION OF THE INVENTION

[0017] In the following detailed description, numerous details are set forth to provide a thorough understanding of the present invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the present invention.

[0018] Applicant recognized that a user-friendly way to authenticate a technician dispatched by a medical device manufacturer is against the medical device manufacturer's corporate login page, while a user-friendly way to authenticate a hospital user is against the hospital's corporate login page.

[0019] Additionally, applicant has recognized the need for an audit trail with usernames on medical devices, which is not possible in the prior art where the medical device only knows whether the user is authorized or not, but does not know who the user is (i.e., does not know the user's username or other identifying information).

[0020] Applicant has recognised that for user authentication on a device to be effective, some or all of the following elements should ideally be part of the process: 1) User authentication against an online database of users; 2) an audit trail on the medical device that stores the username and user access level; 3) One-time password, 4) a non-repudiable log of user activity stored on the medical device; and 5) A process that remains secure even if a hacker gains access to a medical device.

[0021] Referring now to FIG. 2, FIG. 2 illustrates an exemplary system 50 for authenticating a user of a medical device 12 using an online database of users. The system 50 comprises a mobile device, here a smartphone 51 having an application 53 (e.g., a web browser or standalone application) capable of accessing the Internet, and a medical device 12 having a token generator and 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, whether optical or non-optical, to perform the functions described herein. Alternatives include, but are not limited to, one-dimensional barcodes, SnapTags, near-field communication (NFC), and Bluetooth. In the case of wireless means such as NFC, it will be understood that the act of scanning a code as described with reference to the examples herein would instead involve triggering communication between the mobile device and the medical device via embedded circuitry in the respective devices associated with the relevant communication protocol (e.g., a near-field communication chipset or integrated circuit configured to send and receive wireless communications). 3A and 3B, which illustrate the screens seen by user 10 in this example.

[0022] In the system 50, when a user 10 wishes to log in to a medical device 52, the user 10 must first type their username, such as their email address, into the QR generator and authorizer 54, such as via a window 70 (FIG. 3A) on the medical device screen 58 (FIG. 2). Note that the terms “token generator” (and its cousin “QR generator”) and authorizer, as used herein as nouns, should be understood to refer to functional blocks of software code having instructions that cause a processor on the medical device to perform the action associated with the noun, such as, in the case of a QR generator, generating a QR code. The QR generator 54 may then generate a QR code 72 (FIG. 3A) based at least on the received username and display the resulting QR code 72 on the screen 58. The user 10 may scan the QR code with a dedicated application 53 (FIG. 2) on the smartphone 51, or alternatively, the QR code may include a URL (universal resource locator) that forwards the user to an application on the cloud, for example, an https address with some query parameters. In the latter case, the user can use any general-purpose QR code scanner application on their smartphone. In both cases, the application establishes communication between the mobile device 51 and the authorization server 56 (FIG. 3), which may cause the mobile device to display the hospital's or medical device 52's manufacturer's corporate login page 74 (FIG. 3B). The user 10 may then log in to the authorization server 56 via the login page 74. After successful authentication, the authorization server 56 may retrieve the user's 10's access level from an online database of users and issue the user 10 a corresponding OTP (one-time password) 76 that is displayed on the smartphone 51 and then entered by the user 10 into the mobile device via field 78 of window 72 (FIG. 3A). From the OTP 76, the QR generator and authorizer 54 (FIG. 2) may determine the user's 10's authorization according to the entered OTP and grant access accordingly.The medical device 52 may then log all activity of the user 10 on the medical device 52 in an access / activity log 60 .

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

[0024] Reference is now made to FIG. 4, which details the elements of system 50, and FIG. 6, which details the method implemented by system 50.

[0025] At the factory, each medical device 52 may be issued a private / public key pair, which may be generated by any known asymmetric encryption algorithm, such as the RSA algorithm, and each medical device 52 may be shipped with the public key, labeled 80 (FIG. 5), stored therein, as well as a serial number 81. The corresponding private key 83 may be stored in a private key database 84, known only to the manufacturer's web server 82, which lists the private keys 83 along with their associated serial numbers 81. The web server 82 may keep the private keys 83 secret and use them as described below. For example, to keep the private keys secret, the web server 82 may store the private keys in a hardware security module (HSM), such as an HSM device that complies with Federal Information Processing Standard Publication 140-2 (FIPS PUB 140-2) Level 3 standard (or higher). In this case, the private key database 84 may store a pointer to the HSM instead of the private key itself.

[0026] The web server 82, which may be the authorization server 56 for the manufacturer and may contact the hospital authorization server 56 for hospital users, may also have an authorization database 86 that stores the permissions 87 of currently authorized users 10 along with associated usernames 85, which may be email addresses or any other type of username.

[0027] The medical device 52 only knows the public key, so even if a hacker reverse-engineers all of the encryption keys and algorithms encoded in the medical device 52, they will not be able to log in because they lack the private key stored in the private key database 84 of the web server 82.

[0028] 5 illustrates an embodiment in which a different private / 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 still remain protected; in an alternative embodiment, a single private / public key pair can be used for all medical devices in the field, as long as the private key 83 is sufficiently protected, preferably within a FIPS 140-2 Level 3 (or higher) compliant HSM module. In this condition, the user access / activity log 60 can still be non-repudiable and resistant to reverse engineering.

[0029] 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 usernames 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.

[0030] The web server 82 may include a QR code receiver 79 for receiving QR codes from the smartphone app 53, a user authenticator 88 for authorizing users and logging the authorization in the authorization log 22, and a QR code decoder 89 for decoding QR codes, 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 medical device serial numbers for which the requests are made, and a list of allowed and denied requests.

[0031] In some embodiments, the QR code may include a URL address with query parameters, and all necessary information may be embedded in the query parameters of the URL address, in which case the QR code receiver 79 may receive all of the information in the query parameters of the URL without having to decode the QR code.

[0032] When a user 10 requests to log in to a medical device 52, the QR generator and authorizer 54 may request the user's email address (or username) and, optionally, the user's requested access level (step 100 of FIG. 6 ). In one embodiment, the user 10 may specify the user's requested access level by selecting one of the options “technician,” “doctor,” or “nurse” in a multiple-selection 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 enable different permission levels. For example, a technician may be allowed to perform calibration tasks but may not have access to patient names, while doctors and nurses may be able to see patient names but may not have access to perform technical maintenance tasks on the medical device 52.

[0033] In response, the QR generator 54 may generate 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 (step 102). Optionally, the hidden file in the volatile memory may also include the calculated expiration date.

[0034] For example, user 10 may have an email address alice@jnj.com and request to log in with a "technician" access level. In this example, the hidden files in the volatile memory of the medical device may appear as follows:

[0035] [Table 1]

[0036] The QR generator and validator 54 may calculate the ExpireTime field as "NOW + some duration," for example, "NOW + 15 minutes." The expiration date may enable the web server 52 to provide a meaningful error message if a user attempts to obtain the OTP after the expiration date. Alternatively, the QR generator and validator 54 may be designed to reject the OTP after some predetermined amount of time. Thus, even with this alternative embodiment, the medical device 52 may be secure and still resistant to replay attacks even without an expiration date in the hidden file.

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

[0038] The QR generator and authenticator 54 may encrypt the hidden file with its public key 80 (step 104) and construct a URL pointing to the web server 82 using the encrypted hidden file and, optionally, the serial number 81 of the medical device 52 as query parameters in the URL. The QR generator and authenticator 54 may encode the URL into the QR code 72 (FIG. 4A) (step 106). Even if someone were to decode the QR code 72, the only information available would be the URL, which contains an encrypted version of the hidden file and, optionally, the serial number 81. The hidden file, encrypted with the public key 80, can only be decrypted with a private key 83 that is accessible only to the web server 82. Therefore, no one can discover the OTP encoded in the QR code 72. RSA, Elliptic Curve Cryptography (ECC), or any other asymmetric algorithm may be used for key generation, data encryption, and decryption.

[0039] A user may scan QR code 72 with a generic camera application on smartphone 51, which may direct a web browser in smartphone 51 to a URL address encoded in QR code 72, which may be hosted on authentication web server 82, along with specified query parameters. For example, the URL may look like this:

[0040] [Table 2]

[0041] 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, for example, 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 transfer it to the QR code receiver 79.

[0042] The authentication web server 82 may authenticate the user via the enterprise login page (step 108). For example, the web server 82 may 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. Alternatively, for example, if the requested access level is "technician," the web server 82 may assume the user is a technician employed by the manufacturer, while if the requested access level is either "doctor" or "nurse," the web server 82 may assume the user is a hospital user. If the user is a technician employed by the medical device manufacturer, the web server 82 may redirect the user to the manufacturer's enterprise login page. If the user is a hospital user, the web server 82 may redirect the user to the hospital's enterprise login page. The web server 82 and the enterprise login page may communicate via an authentication protocol such as OpenID, OAuth 2.0, or SAML. Upon successful authentication, the corporate login page may return the user to the web server 82, which may transmit the encrypted hidden file and, optionally, the serial number of the medical device 52 to the QR code decoder 89. The process continues to step 112.

[0043] 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 contain 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 either before or after scanning the QR code. If the application successfully authenticates the user and the QR code 72 is scanned, the process continues at step 112.

[0044] In step 112, the QR code decoder 89 may access the private key database 84 to find the private key 83 associated with the transmitted serial number 81. Alternatively, if all medical devices are shipped with the same private / public key, the QR code decoder 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 decoder 89 does not need to receive the private key 83; instead, the QR code decoder may send a decryption command along with the hidden file to the HSM and receive the decrypted hidden file from the HSM. The QR code decoder 89 may then send the now decrypted hidden file to the user authenticator 88.

[0045] 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 a corporate login page. The user authenticator 88 may further verify, via the authorization database 86, that the user 10 does have authorization for the access level specified in the RequestedAccessLevel field, and may verify that the ExpireTime field is in the future based on its clock 24 (FIG. 3). If all conditions are met, the user authenticator 88 may display the associated OTP 76 (FIG. 4B) as cleartext on the OTP page 77 (step 116).

[0046] 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, which may verify the entered OTP against the OTP field in the hidden file and then grant the user 10 access to perform all tasks allowed by the user's access level.

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

[0048] In an alternative embodiment, each medical device 52 may be shipped with the same public key. 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 allow a way to change the key from time to time, for example, after several years, or when a new version of the medical device 52 is released to the market, or if the private key is compromised.

[0049] To enable key exchange, an ID may be assigned to each private / public key pair. Initially, all medical devices 52 are 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 encodes the ID of the public key used for encryption into the QR code 72 (or into a query parameter of the URL encoded in the QR code) along with the encrypted hidden file.

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

[0051] If the manufacturer decides to decommission the old public key with ID=1, the private key with ID=1 is removed from the database or HSM of the web server 82. After this removal, authentication functions will not work for medical devices 52 that have the old public key with ID=1.

[0052] It can be seen 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" instruct the QR code decoder 89 on which private key to use to decode the QR code 72. In embodiments involving a "Serial Number," there may be a separate private / public key pair for each individual medical device, whereas in embodiments involving a "Key ID," there may be one private / public key for each group of medical devices, for example, for all medical devices manufactured in the same year. However, the usage of the "Key ID" and "Serial Number" may be similar.

[0053] In the previous embodiment, the user had to specify the access level they requested. In an alternative embodiment, the user 10 may receive the QR code 72 by simply writing their username without specifying the 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 appear as follows:

[0054] [Table 3]

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

[0056] Assuming that the web server 82 may have already authenticated the user 10 via a corporate login page or via some other method, the permission database 86 may list the permissions of the user 10, so that the web server 82 may select the relevant OTP (from the OtpIfTechnician, or OtpIfPhysician, or OtpIfNurse field) according to the permission level of the user 10.

[0057] For example, if the user 10 is a physician, the web server 82 may only expose the OtpIfPhysician field to the user as an OTP. The user 10 may enter this OTP into the medical device 52, from which the medical device 52 may automatically determine that the person is a physician. The medical device 52 may grant authorization accordingly.

[0058] Unless specifically stated otherwise, and as will be apparent from the foregoing discussion, discussions utilizing terms such as "processing," "computing," "calculating," "determining," and the like throughout this specification should be understood to refer to the actions and / or processes of any type of general-purpose computer, e.g., client / server system, mobile computing device, smart appliance, cloud computing unit and / or similar electronic computing device, etc., that manipulates data in the registers and / or memory of the computing system and / or transforms that data into other data in the memory, registers, or other such information storage, transmission, or display device of the computing system.

[0059] Embodiments of the present invention may include an apparatus for performing the operations herein. This apparatus may be specially constructed for a desired purpose, or may comprise a computing device or system, typically having at least one processor and at least one memory, selectively activated or reconfigured by a computer program stored in the computer. The resulting apparatus, when instructed by software, may transform a general-purpose computer into an inventive element as discussed herein. The instructions may define an inventive device operating on a desired computer platform. Such a computer program may be stored on any type of computer-readable storage medium, such as a disk, including, but not limited to, optical disks, magneto-optical disks, read-only memory (ROM), volatile and non-volatile memory, random access memory (RAM), electrically programmable read-only memory (EPROM), electrically erasable and programmable read-only memory (EEPROM), magnetic or optical card, flash memory, disk-on-key, or any other type of medium suitable for storing electronic instructions and capable of being coupled to a computer system bus. The computer-readable storage medium may also be implemented in cloud storage.

[0060] Some general purpose computers, including commercial mobile devices and smart phones, may be equipped with at least one communication element to enable communication with a data network and / or a mobile communication network.

[0061] The processes and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the desired methods. The desired structure for a variety of these systems will be apparent from the description below. Additionally, embodiments of the present invention are not described with reference to any particular programming language. It will be understood that a variety of programming languages ​​can be used to implement the teachings of the present invention as described herein.

[0062] While certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes, and equivalents will 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 as fall within the true spirit of the invention.

[0063] [Embodiment] (1) A medical device comprising: a processor; and a storage medium having stored thereon instructions, the instructions, when executed by the processor, causing 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 the current user; transmitting the authentication token to an online authorization server for the medical device for decryption upon authentication of the current user; 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; and generating an access / activity log for tracking and storing the current user's activities according to the username once the current user is authenticated by the online authorization server. (2) The medical device of embodiment 1, wherein generating the authentication token includes generating a QR code using a public key cryptograph to encrypt information about the QR code. (3) A medical device as described in embodiment 2, wherein the information includes a randomly generated OTP and a requested access level, and the authorization server displays the OTP if the current user has permission for the requested access level. (4) The medical device of embodiment 2, wherein the information includes multiple randomly generated OTPs, each for a different access level, and the authorization server displays a selected one of the OTPs associated with the current user's access level. (5) A medical device as described in embodiment 2, wherein the information includes the username.

[0064] (6) The medical device of embodiment 5, wherein the information also includes an expiration date. (7) A medical device as described in embodiment 2, wherein the information is added as a query parameter to the URL (universal resource locator) of the authorization server. (8) A medical device as described in embodiment 2, wherein the information includes a serial number of the medical device. (9) A medical device as described in embodiment 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, the instructions, when executed by the processor, causing the medical device to: receiving an authentication token from a mobile device of a user of the medical device, the authentication token providing at least encrypted text, the encrypted text including at least an OTP and user identification information; decrypting the authentication token to access a private key associated with the medical device and to decrypt a 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 enabling the user to log in to the authorization server for authentication and displaying at least one OTP if the user successfully logs in to the server.

[0065] (11) The authorization server of embodiment 10 further comprises an authorization database for listing a number of users and their associated authorization levels, and the user authenticator for selecting one OTP from the at least one OTP according to the associated authorization level of the user. (12) An authorization server as described in embodiment 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) An authorization server as described in embodiment 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) An authorization server as described in embodiment 10, wherein the authentication token includes at least one of a QR code, a SmartTag, or NFC communication. (15) A system comprising a medical device described in embodiment 1 and an authorization server described in embodiment 10.

[0066] (16) The system of embodiment 15, wherein the medical device generating the authentication token includes generating a QR code, and the QR calculator and authorizer include using a public key cryptographer to encrypt information about the QR code. (17) The system of embodiment 16, wherein the information includes a randomly generated OTP and a requested access level, and the authorization server displays the OTP if the current user has permission for the requested access level. (18) The system of embodiment 15, wherein the authorization server further comprises: an authorization database for listing a number of users and their associated authorization levels; and the user authenticator for selecting one OTP from the at least one OTP according to the associated authorization level of the user. (19) The system described in embodiment 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 described in embodiment 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.

Claims

1. 1. A medical device comprising: a processor; and a storage medium having instructions stored thereon, the instructions, when executed by the processor, causing 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 the current user; transmitting the authentication token to an online authorization server for the medical device for decryption upon authentication of the current user; 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; and generating an access / activity log for tracking and storing the current user's activities according to the username once the current user is authenticated by the online authorization server.

2. The medical device of claim 1 , wherein the generating the authentication token comprises generating a QR code using a public key cryptograph to encrypt information about the QR code.

3. 3. The medical device of claim 2, wherein the information includes a randomly generated OTP and a requested access level, and the authorization server displays the OTP if the current user has permission for the requested access level.

4. 3. The medical device of claim 2, wherein the information includes a plurality of randomly generated OTPs, each for a different access level, and the authorization server displays a selected one of the OTPs associated with the current user's access level.

5. The medical device of claim 2 , wherein the information includes the username.

6. The medical device of claim 5 , wherein the information also includes an expiration date.

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

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

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

10. 1. An authorization server for a medical device comprising: a processor; and a storage medium having instructions stored thereon, the instructions, when executed by the processor, causing the medical device to: receiving an authentication token from a mobile device of a user of the medical device, the authentication token providing at least encrypted text, the encrypted text including at least an OTP and user identification information; decrypting the authentication token to access a private key associated with the medical device and using the associated private key to decrypt a public code encrypted portion of the authentication token into at least a username of the user and at least one OTP for the user; and enabling the user to log in to the authorization server for authentication and displaying at least one OTP if the user successfully logs in to the server.

11. 11. The authorization server of claim 10, further comprising: a permission database for listing a number of users and their associated permission levels; and the user authenticator for selecting one OTP from the at least one OTP according to the associated permission level of the user.

12. The authorization server of 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 of 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 of claim 10 , wherein the authentication token comprises at least one of a QR code, a SmartTag, or an NFC communication.

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

16. 16. The system of claim 15, wherein the medical device generating the authentication token comprises generating a QR code, and the QR calculator and authorizer comprises using a public key cryptographer to encrypt information about the QR code.

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

18. 16. The system of claim 15, wherein the authorization server further comprises: an authorization database for listing multiple users and their associated authorization levels; and the user authenticator for selecting one OTP from the at least one OTP according to the associated authorization 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. 16. 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