SYSTEM AND METHOD FOR TIME-BASED ONE-TIME PASSWORD MANAGEMENT FOR MEDICAL DEVICES - Patent application

Abstract

A data monitoring system is provided that includes a server communicatively coupled to client devices and data modules over a network. In a remote link architecture (1500), a server stores a private key of a public-private key pair associated with a data module (102), receives a request from a client device for authenticated access to the data module, and generates an authentication key based on at least the private key and a time. The client device generates a request for authenticated access to the data module and sends the request to the server. The data module stores a private key of a public-private key pair associated with the data module, generates an authentication key based on at least the private key and a time, and grants access to the data module if the authentication key generated by the data module matches the authentication key generated by the server.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 560,448, filed Sep. 19, 2017, the entire contents of which are incorporated herein by reference.

[0002] FIELD OF THEINVENTION The present disclosure relates to systems and methods for implementing a time-based password algorithm that allows users to securely manage medical devices. [Background technology]

[0003] background Medical devices that monitor patients are often connected to a network for remote access. Many of these medical devices require a password to change the administrative settings on the medical device. Often these passwords are static and must be changed manually after a certain amount of time.

[0004] However, there has long been a need to implement additional security measures for network-connected medical devices to protect patient data and hinder successful security attacks. Summary of the Invention

[0005] The present disclosure relates to a data monitoring system including a server communicatively coupled to a client device and a data module via a data network. The server is configured to store a private key of a public-private key pair associated with the data module, receive a request from the client device for authenticated access to the data module, and generate an authentication key based on at least the private key and a time. The authentication key can be used to grant authenticated access to the data module. The client device is configured to generate a request for authenticated access to the data module and send the request to the server. The data module includes a user interface configured to display data and receive user input. The data module is configured to store a private key of a public-private key pair associated with the data module, receive data from a medical device, generate an authentication key based on at least the private key and a time, and grant access to the data module in response to a determination that the authentication key generated by the data module and the authentication key generated by the server match.

[0006] According to one embodiment, the data module is configured to display a message indicating an authentication failure in response to determining that the authentication key generated by the data module and the authentication key generated by the server do not match. In some embodiments, the data module is configured to grant authenticated access using a challenge-response protocol.

[0007] In certain embodiments, the data module may transmit data to the client device upon successful authentication.

[0008] According to some embodiments, the time is determined independently by the data module and the server, while in other embodiments the time determined by the data module is synchronized with the time determined by the server.

[0009] In certain implementations, the times are synchronized by rounding the time determined by the data module to a time interval and rounding the time determined by the server to that time interval so that the determined times are the same.

[0010] According to some implementations, the time interval is adjustable to set lower or upper limits on the acceptable synchronization accuracy.

[0011] According to one embodiment, the time includes at least one of TAI, UTC, and UNIX time, hi some embodiments, the time is the current time.

[0012] In certain embodiments, the request for authenticated access to the data module includes additional information for instructing the data module. According to some embodiments, the additional information includes a request for access to the data module. In some embodiments, the additional information includes a time, the time being determined by the server. In another embodiment, the additional information includes a request for the data module to enter a maintenance mode.

[0013] According to one embodiment, the authentication key is a one-time authentication key. In a particular embodiment, the authentication key expires after a period of time.

[0014] In certain embodiments, the private key is loaded into the data module during at least one of the manufacture and distribution of the data module. According to some embodiments, the private key is further stored by the server after the private key is loaded into the data module.

[0015] A second aspect of the present disclosure relates to a method for securely monitoring a data module receiving data from a medical device. The method includes storing, at a server, a private key of a public-private key pair associated with the data module. The method further includes receiving, at the server, a request from a client device for access to the data module. The method further includes generating, at the server, an authentication key based on at least the private key and a time. The authentication key can be used to grant authenticated access to the data module. The method further includes receiving, at the server, an indication from the data module that the server-generated authentication key has been entered. The method also includes granting authenticated access to the data module in response to determining that the authentication key generated by the server and the authentication key generated by the data module match. In one embodiment, the authentication key generated by the data module is generated based on at least the private key and a time. [The present invention 1001] storing a private key of a public-private key pair associated with the data module; receiving a request from a client device for authenticated access to the data module; and generating an authentication key based on at least the private key and a time of day for use in granting authenticated access to the data module; a server communicatively coupled to the client device and the data module via a data network, the server configured to generating said request for authenticated access to said data module; and Send the request to the server The client device configured to storing a private key of the public-private key pair associated with the data module; Receive data from medical devices, generating an authentication key based on at least the private key and the time; and granting authenticated access to the data module in response to determining that the authentication key generated by the data module and the authentication key generated by the server match; the data module including a user interface configured to display data and receive user input; A data monitoring system. [The present invention 1002] The system of the present invention 1001, wherein the data module is further configured to display a message indicating authentication failure in response to a determination that the authentication key generated by the data module does not match the authentication key generated by the server. [The present invention 1003] The system of the present invention 1001, wherein the data module is configured to allow authenticated access using a challenge-response protocol. [The present invention 1004] The system of the present invention 1001, wherein the data module is configured to transmit data to the client device upon successful authentication. [The present invention 1005] The system according to any one of claims 1001 to 1004, wherein the time is determined independently by the data module and the server. [The present invention 1006] The system of the present invention 1005, wherein the time determined by the data module is synchronized with the time determined by the server. [The present invention 1007] The system of the present invention 1006, wherein the times are synchronized by rounding the time determined by the data module to a time interval and rounding the time determined by the server to the time interval so that the determined times are the same. [The present invention 1008] The system of the present invention 1007, wherein the time interval is adjustable to set lower or upper limits on the acceptable synchronization accuracy. [The present invention 1009] The system of any one of 1001 to 1008, wherein the time includes at least one of TAI, UTC, and UNIX time. [The present invention 1010] The system according to any one of 1001 to 1009 of the present invention, wherein the time is the current time. [The present invention 1011] Any of the systems of claims 1001 to 1010, wherein the request for authenticated access to the data module includes additional information for instructing the data module. [The present invention 1012] The system of the present invention 1011, wherein the additional information includes a request for access to the data module. [The present invention 1013] The system of any of claims 1011 and 1012, wherein the additional information includes the time, the time being determined by the server. [The present invention 1014] The system of any one of claims 1011 to 1013, wherein the additional information includes a request for the data module to enter a maintenance mode. [The present invention 1015] The system according to any one of claims 1001 to 1014, wherein the authentication key is a one-time authentication key. [The present invention 1016] The system of the present invention 1015, wherein the authentication key expires after a certain period of time. [The present invention 1017] The system of any one of claims 1001 to 1016, wherein the private key is loaded into the data module during at least one of the time of manufacture or distribution of the data module. [The present invention 1018] The system of the present invention 1017, wherein the private key is further stored by the server after the private key is loaded into the data module. [The present invention 1019] 1. A method for securely monitoring a data module that receives data from a medical device, the method comprising the steps of: storing, at the server, a private key of a public-private key pair associated with the data module; receiving, at the server, a request from a client device for access to the data module; generating, at the server, an authentication key used to grant authenticated access to the data module based on at least the private key and a time of day; receiving, at the server, an indication from the data module that the authentication key generated at the server has been entered; and In response to determining that the authentication key generated by the server and the authentication key generated by the data module match, granting authenticated access to the data module. [The present invention 1020] The method of claim 1019, wherein the authentication key generated by the data module is generated based on at least the private key and the time. [Brief description of the drawings]

[0016] These and other objects and advantages will become apparent from the following detailed description considered in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout.

[0017] [Figure 1] FIG. 1 is a schematic diagram illustrating a remote link architecture, arranged in accordance with one or more aspects of the present disclosure. [Diagram 2] 1 is a flow diagram of method steps for transferring data from a medical device to a server according to an aspect of the present disclosure. [Diagram 3] 1 is a flow diagram of method steps for transferring data from a medical device to a server according to an aspect of the present disclosure. [Figure 4] FIG. 1 is a schematic diagram illustrating a remote link architecture, arranged in accordance with one or more aspects of the present disclosure. [Diagram 5] 4 is a flow diagram of method steps for initializing a remote link according to one aspect of the present disclosure. [Figure 6] FIG. 1 is a schematic diagram illustrating a remote link architecture, arranged in accordance with one or more aspects of the present disclosure. [Figure 7] FIG. 1 is a schematic diagram illustrating a remote link architecture, arranged in accordance with one or more aspects of the present disclosure. [Figure 8] 1 is a schematic diagram illustrating a medical device configured in accordance with one or more aspects of the present disclosure. [Figure 9] FIG. 1 illustrates an example medical device controller configured in accordance with one or more aspects of the present disclosure. [Figure 10] FIG. 1 illustrates an example image displayed on a medical device controller screen, arranged in accordance with one or more aspects of the present disclosure. [Figure 11] 11 illustrates the example image of FIG. 10 after removing a selected portion of the image, arranged in accordance with one or more aspects of the present disclosure. [Figure 12] 12 illustrates an exemplary image of the remaining portion of the image of FIG. 11, arranged in accordance with one or more aspects of the present disclosure. [Figure 13] 13 and 14 are flow diagrams of method steps for extracting data from an image and determining the validity of the extracted data according to one aspect of the present disclosure. [Figure 14] 13 and 14 are flow diagrams of method steps for extracting data from an image and determining the validity of the extracted data according to one aspect of the present disclosure. [Figure 15] 1 is a schematic diagram illustrating a remote link architecture, arranged in accordance with one or more aspects of the present disclosure. [Figure 16] 4 is a flow diagram of method steps for authenticating a connection between a remote link and a server according to one aspect of the present disclosure. [Figure 17] 4 is a flow diagram of method steps for authenticating a connection between a remote link and a server according to one aspect of the present disclosure. [Figure 18]4 is a flow diagram of method steps for authenticating a connection between a remote link and a server according to one aspect of the present disclosure. [Figure 19] 4 is a flow diagram of method steps for authenticating a connection between a remote link and a server according to one aspect of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] Detailed Description 1 is a schematic diagram of a remote link architecture 100. The remote link architecture 100 includes a remote link 102, a client device 104, a remote link router (RLR) 150, a web load balancer 108, a video load balancer 110, a web server 114, a video server 116, a random access memory (RAM) data type storage 118, a document data type storage 120, and a web socket server 122.

[0019] The remote link 102 may be embedded in a medical device monitoring a patient in a hospital, clinic, the patient's home, or another location. The remote link 102 captures images and distributes video streams from the medical device display and transmits the images and video to a remote link router 150. The remote link architecture 100 may include multiple remote links 102. The remote links 102 communicate with other parts of the remote link architecture 100 through the RLR 150. The RLR 150 includes an RLR load balancer 106 and an RLR server 112. The RLR 150 may include multiple RLR servers 112. The RLR server 112 may include a custom protocol used to communicate with one or more remote links 102. The RLR load balancer 106 manages the load on one or more RLR servers 112. The RLR load balancer 106 may generate priorities for the multiple remote links 102. The priorities may be based on preferences obtained from the client device 104. In another aspect, the priority is based on preferences obtained from the remote link 102. In another aspect, the priority is based on preferences obtained from the RLR server 112.

[0020] The client device 104 may be a personal computer, tablet, or mobile device with an Internet connection. A medical practitioner using the client device 104 may want to obtain information from one or more remote links 102. Images captured by the remote links 102 may be accessed by the client device 104. In addition, if a medical practitioner wants to watch a live video stream of a medical device with a remote link 102 integrated therein, the client device may display the video stream. The remote link architecture may include multiple client devices 104. As long as the client device can access the remote links 102, one client device 104 may access multiple remote links 102.

[0021] The WEB load balancer 108 controls the load on one or more WEB servers 114. The WEB servers 114 may include mechanisms for clients to view information, data, and video streams from one or more remote links 102. The WEB load balancer 108 may generate priorities for multiple client devices 104. The priorities may be based on preferences obtained from the client devices 104. In other aspects, the priorities are based on preferences obtained from the remote links 102. In other aspects, the priorities are based on preferences obtained from the WEB servers 114. The WEB socket server 122 may push messages to a group of client devices 104. When a client device 104 connects to the WEB server 114, the client device 104 registers with the WEB socket server 122 for messages of any of the one or more remote links 102. The WEB socket server 122 will receive messages applicable to the one or more remote links 102. This message along with the associated data is broadcast from those remote links 102 to all connected client devices 104 for updating.

[0022] The video load balancer 110 controls the load on one or more video servers 116. The video servers 116 may be receivers and senders of video streams from one or more remote links 102. The video load balancer 110 may generate priorities for the multiple client devices 104. The priorities may be based on preferences obtained from the client devices 104. In other aspects, the priorities are based on preferences obtained from the remote links 102. In another aspect, the priorities are based on preferences obtained from the video servers 116.

[0023] The RAM data type storage 118 may be a volatile storage that can be accessed quickly. The RAM data type storage 118 may include dynamic random access memory (DRAM), static random access memory (SRAM), or another type of fast volatile memory. Images captured by the remote link 102 may be stored in the RAM data type storage 118 before being sent to the client device 104. The RAM data type storage 118 may also store video streams captured by the remote link 102. The document data type storage 120 may be a non-volatile storage that can maintain data for a long period of time. The document data type storage 120 may be a hard disk, an optical disk, a solid state drive (SSD), or another type of non-volatile memory.

[0024] A process 200 for transferring images from a remote link 102 to a remote link router server 112 is shown in Figure 2. Process 200 begins with connecting the remote link 102 to the Internet at step 202. Step 202 may include initializing the remote link 102, as described below in process 500 of Figure 5.

[0025] The process 200 continues with sending a first signal from the remote link 102 to the RLR 150 indicating that the remote link 102 is connected to the Internet, as step 204. The first signal may be sent directly to the RLR load balancer 106. In another aspect, the first signal may be sent directly to the RLR server 112.

[0026] The process 200 continues at step 206 with the RLR 150 sending a command to the remote link 102 to begin capturing an image. For example, the remote link 102 captures an image from a medical device using an image capture unit 626, described below.

[0027] The process 200 continues at step 208 with transferring the image from the remote link 102 to the RLR 150. For example, an RLR load balancer manages the transfer of the image from the remote link 102 to the RLR server 112. Once the image is transferred to the RLR server 112, the process 200 proceeds to step 210.

[0028] The process 200 continues at step 210 with broadcasting a second signal from the RLR 150 indicating that the remote link 102 has captured an image. For example, the RLR 150 broadcasts the second signal so that the web server 114 is notified that the RLR 150 has an image captured by the remote link 102.

[0029] The process 200 continues at step 212 with receiving at the WEB server 114 a second signal broadcast from the remote link 102. For example, the WEB server 114 receives the signal broadcast from the RLR 150 such that the WEB server 114 is notified that the RLR 150 has an image captured by the remote link 102.

[0030] The process 200 ends with storing the image at the web server 114 at step 214. The image may be stored in the RAM data type storage 118. For example, the RLR 150 transfers the image to the web server 114, which then transfers the image to the RAM data type storage 118. In one aspect, the RLR 150 may transfer the image directly to the RAM data type storage 118.

[0031] A process 300 for transferring a video stream from a remote link 102 to a client device 104 is shown in Figure 3. The process 300 begins at step 302 with sending a request from the client device 104 to a WEB server 114 to view a video stream from the remote link 102. The request may be routed through a WEB load balancer 108 before being sent to the WEB server 114. In one aspect, the request may include information identifying the remote link 102 to be accessed.

[0032] The process 300 continues at step 304 with broadcasting a request from the WEB server 114. For example, the WEB server 114 notifies the RLRs 150 that the client device 104 has requested to view a video stream from the remote link 102 by broadcasting the request to all RLRs 150.

[0033] The process 300 continues at step 306 with receiving the request at the RLR 150. For example, the RLR server 112 receives the request from the web server 114. In one aspect, the RLR 150 receives the request after determining that the request identifies a remote link 102 communicatively coupled to the RLR 150.

[0034] The process 300 continues at step 308 with sending a command from the RLR 150 to the remote link 102 to transmit the video stream to the video server 116. For example, the RLR server 112 sends a signal to the remote link 102 via the RLR load balancer 106 to initiate the process of transmitting the video stream from the remote link 102 to the video server 116.

[0035] The process 300 continues at step 310 with sending the video stream from the remote link 102 to the video server 116. In one aspect, the remote link 102 sends the video stream to a video load balancer 110, which determines which video server 116 to send the video stream to. The video load balancer 110 may make the decision based on the load of the video server 116 and the priority of the remote link 102 and the client device 104.

[0036] The process 300 continues at step 312 with receiving the video stream at the video server 116. For example, once the video load balancer 110 determines which video servers 116 are available to receive the video stream, the video server 116 receives the video stream.

[0037] The process 300 concludes with transmitting the video stream from the video server 116 to the client device 104. For example, the video server 116 begins forwarding the video stream to the client device 104 via the video load balancer 110.

[0038] 4 shows a schematic diagram of a remote link architecture 400. The remote link architecture 400 includes a remote link 402, a client device 404, an RLR 450, a document data type storage 420, an HTTP service 430, and a cloud 460.

[0039] The remote link 402 is similar to the remote link 102 and may be incorporated into medical equipment monitoring a patient in a hospital, clinic, the patient's home, or another location. The remote link 402 may capture images and deliver video streams from the medical equipment display and transmit images and video to a remote link router 450. The remote link architecture 400 may include multiple remote links 402. The remote link 402 communicates with other parts of the remote link architecture 400 via the RLR 450. The RLR 450 is similar to the RLR 150 described above.

[0040] The client device 404 is similar to the client device 104 and may be a personal computer, tablet, or mobile device with an Internet connection. A medical practitioner using the client device 404 may want to obtain information from one or more remote links 402. Images captured by the remote links 402 may be accessed by the client device 404. In addition, if a medical practitioner wants to watch a live video stream of a medical device with an integrated remote link 402, the client device may display the video stream. The remote link architecture may include multiple client devices 404. One client device 404 may access multiple remote links 402, as long as the client device can access the remote links 402. The client device 404 may communicate with the RLR 450 via the cloud 460. The cloud 460 represents a network of Internet-based devices and connections, such as servers, storage, applications, etc.

[0041] The document data type storage 420 may be similar to the document data type storage 120 and may be a non-volatile storage capable of maintaining data for a long period of time. The document data type storage 420 may be a hard disk, an optical disk, a solid state drive (SSD), or another type of non-volatile memory. The document data type storage 420 may store Wi-Fi authentication information or other initial configuration information obtained from one or more client devices 404 or from the RLR 450. The document data type storage 420 may transmit the Wi-Fi authentication information or other initial configuration information to the RLR 450 or directly to one or more remote links 402.

[0042] The HTTP service 430 may be a framework that provides the ability for the RLR 450 to make HTTP requests. The RLR 450 may use the HTTP service 430 to obtain Wi-Fi authentication information or other initial configuration information and store that information in the document data type storage 420.

[0043] A process 500 for initializing the remote link 402 is shown in Figure 5. The process 500 begins with connecting the remote link 402 to an LTE network at step 502. In another aspect, the remote link 402 may connect to a 3G or 4G network.

[0044] The process 500 continues with the remote link 402 sending a first signal to the RLR 450 indicating that the remote link 402 is connected to the LTE network at step 504. For example, when the remote link 402 comes online, the remote link 402 sends a signal to the RLR 450 to notify the RLR 450 that it is ready to transmit or receive data. In one aspect, the RLR 450 is also connected to the LTE network.

[0045] The process 500 continues at step 506 with receiving the Wi-Fi authentication information at the RLR 450 from the client device 404. For example, a user enters the Wi-Fi authentication information into the client device 404, which then transmits the Wi-Fi authentication information to the RLR 450. In one aspect, the RLR 450 stores the Wi-Fi authentication information.

[0046] The process 500 then transmits the Wi-Fi authentication information from the RLR 450 to the remote link 402 at step 508. For example, the RLR 450 transmits the Wi-Fi authentication information to the remote link 402 using an LTE network.

[0047] Process 500 continues with connecting remote link 402 to a Wi-Fi network corresponding to the Wi-Fi credentials at step 510. For example, when remote link 402 receives the Wi-Fi credentials, remote link 402 searches for and connects to a Wi-Fi network identified by the Wi-Fi credentials.

[0048] The process 500 ends with the remote link 402 sending a second signal to the RLR 450 indicating that the remote link 402 is connected to the Wi-Fi network. For example, to confirm that the remote link 402 has successfully connected to the Wi-Fi network, the remote link 402 sends a signal to the RLR 450 indicating the successful connection using the Wi-Fi network. In another aspect, the remote link 402 sends a signal to the RLR 450 using the LTE network if the connection is faster than the Wi-Fi network. In one aspect, if the remote link 402 cannot connect to the Wi-Fi network, the remote link 402 sends a signal to the RLR 450 using the LTE network indicating that the connection was not successful.

[0049] 6 shows a schematic diagram of a remote link architecture 600. The remote link architecture 600 includes a medical device 624, a remote link 102, and a media server 116. The medical device 624 may include a sensor 626. The remote link 102 may include an image capture unit 628. The media server 116 may include an optical character recognition unit 630 and a motion data unit 632.

[0050] The medical device 624 may be a medical device monitoring a patient in a hospital, a clinic, the patient's home, or another location. The medical device 624 includes a sensor 626 that may be measuring and recording health signals from the patient. The sensor 626 may be a pressure sensor, a temperature sensor, a flow sensor, a voltage sensor, a current sensor, a light sensor, or an audio sensor.

[0051] The image capturer 628 may be an application that allows the remote link 102 to capture an image from the sensor 626. For example, the image capturer 628 captures an image of the display of the medical device 624. The image of the display of the medical device 624 may include data from the sensor 626 represented alphanumeric or graphically in a waveform plot. The image capturer 628 may convert analog data captured from the sensor 626 into digital data that may be used by the optical character recognition unit 630. For example, the image capturer 628 converts an analog signal from a video graphics array (VGA) connection from the sensor 626. As further described in connection with FIGS. 10-14, optical character recognition (OCR) may be used to convert images of text or shapes into digital data. In another aspect, other OCR equivalents and / or digital signal processing (DSP) may be used to extract data from the image.

[0052] The OCR unit 630 can be an application that electronically converts images of text or shapes into digital data. For example, the OCR unit 630 analyzes images captured by the image capture unit 628 on the remote link 102 to extract data from data embedded in the images. In some cases, the OCR unit 630 can extract data from waveforms.

[0053] In one aspect, the media server 116 may include a DSP unit 634. The DSP unit 634 may be an application that converts images into digital data. For example, the DSP unit 634 converts images captured by the image capture unit 628 on the remote link 102 into digital data. Once in digital form, the media server 116 may identify and / or filter motion and / or medical data embedded in the image. In another aspect, the DSP unit 634 may be used to extract data from a waveform contained in the image. For example, the OCR unit 630 extracts a period from the waveform portion of the image, and the DSP unit 634 uses the period and boundaries of the waveform to extract the motion and / or medical data. By using the period and boundaries of the waveform portion of the image, the DSP unit 634 associates pixels of the waveform portion with units of time. In some aspects, the OCR unit 630 is used to extract units of measurement from the waveform portion of the image, and the DSP unit 634 uses the period and units of measurement to extract the motion and / or medical data. For example, the OCR unit 630 may determine that the waveform portion of the image represents a positioning signal and / or motor current over a 10 second period, and the DSP unit 634 may associate each pixel in the waveform portion with a corresponding positioning signal and / or motor current and a unit of time equal to the period divided by the number of pixels in the waveform portion of the image.

[0054] The operational and / or medical data section 632 may be an application that databases and organizes data extracted from the OCR section 630 and / or DSP section 634. For example, the operational data section 632 identifies the type of data extracted by the OCR section 630 and / or DSP section 634 and categorizes the data into operational and / or medical conditions. The operational and / or medical conditions may include pressure, flow rate, pump speed, temperature, voltage, current, and biometric conditions.

[0055] The remote link architecture 600 may be implemented by processes 200, 300, and 500 to control the bandwidth, quality, and type of video streaming from the remote link device 102. The remote link architecture 600 may be extended to an unlimited number of remote link devices 102 and client devices 104. The OCR unit 630 and the operational data unit 632 may be included in other components of the remote link architecture 100, the remote link architecture 400, the remote link architecture 600, or the remote link architecture 700 (described below).

[0056] 7 is a schematic diagram of a remote link architecture 700. The remote link architecture 700 includes a remote link 102, a client device 104, an RLR 150, a media server 116, a web socket server 122, a web server 114, a cloud 460, a RAM data type storage 118, a document data type storage 120, and a message service 770.

[0057] The remote link 102 may be embedded in medical equipment monitoring a patient in a hospital, clinic, the patient's home, or another location. The remote link 102 may capture images and deliver video streams from the medical equipment display and transmit images and video to a remote link router 150. The remote link architecture 100 may include multiple remote links 102. The remote links 102 communicate with other parts of the remote link architecture 100 via the RLR 150.

[0058] The client device 104 may be a personal computer, tablet, or mobile device with an Internet connection. A medical practitioner using the client device 104 may want to obtain information from one or more remote links 102. Images captured by the remote links 102 may be accessed by the client device 104. In addition, if a medical practitioner wants to watch a live video stream of a medical device with a remote link 102 integrated therein, the client device may display the video stream. The remote link architecture may include multiple client devices 104. As long as the client device can access the remote links 102, one client device 104 may access multiple remote links 102.

[0059] The WEB server 114 may include a mechanism for clients to view information, data, and video streams from one or more remote links 102. The WEB socket server 122 may push messages to a group of client devices 104. When a client device 104 connects to the WEB server 114, it registers with the WEB socket server 122 for messages of any of the one or more remote links 102. The WEB socket server 122 will receive messages applicable to one or more remote links 102. The messages, along with associated data, are broadcast from those remote links 102 to all connected client devices 104 for updates. The message service 770 may manage the transfer of messages between different components of the remote link architecture 700 via the cloud 460. The cloud 460 represents a network of Internet-based devices and connections, such as servers, storage, applications, etc.

[0060] The media server 116 may be a receiver and sender of video streams from one or more remote links 102. The media server 116 may be similar to the video server 116 described above. The media server 116 may also be a receiver and sender of images captured from one or more remote links 102.

[0061] The RAM data type storage 118 may be a volatile storage that can be accessed quickly. The RAM data type storage 118 may include dynamic random access memory (DRAM), static random access memory (SRAM), or another type of fast volatile memory. Images captured by the remote link 102 may be stored in the RAM data type storage 118 before being sent to the client device 104. The RAM data type storage 118 may also store video streams captured by the remote link 102. The document data type storage 120 may be a non-volatile storage that can maintain data for a long period of time. The document data type storage 120 may be a hard disk, an optical disk, a solid state drive (SSD), or another type of non-volatile memory.

[0062] FIG. 8 illustrates an example of a medical device, such as an intravascular blood pump 800, according to certain embodiments. The pump 800 includes a pump handle 810, a pump head 830, a catheter 820 that connects the pump handle 810 to the pump head 830, and a connection hub 860. The catheter 820 is tubular and has a substantially uniform outer diameter 850. The catheter 820 allows the pump head 830 and the pump handle 810 to be in electromechanical communication. The pump handle 810 is in communication with control circuitry that allows control of the pump head 830. The pump head 830 includes electromechanical components that allow the device to perform various tasks within the patient's body, such as pumping blood from a location within the body. The pump head 830 has a diameter 840 that is larger than the diameter 850 of the catheter 820. One example of such a percutaneous pump is the Impella 2.5® system (Abiomed, Inc., Danvers, Massachusetts), which includes a pump and an Automatic Impella Controller (AIC).

[0063] 9 illustrates an example medical device controller 900, such as an AIC, configured in accordance with one or more aspects of the disclosure. The medical device controller 900 provides an interface for monitoring and controlling the functions of the pump 800. The medical device controller 900 may include a display screen 902 that may display images from a video stream, the images representing data associated with a medical device, such as the intravascular blood pump 800, over a period of time. In certain implementations, the display screen 902 displays real-time operational and / or medical data associated with the pump 800.

[0064] FIG. 10 illustrates an exemplary image 1000, for example, displayed on a display screen 902, configured according to one or more aspects of the disclosure. In some configurations, the image 1000 may be captured by an intermediate device or data module, such as the remote link 102, over a network and transmitted to another device, such as the media server 116. The image 1000 may include a waveform 1002. The waveform 1002 represents medical and / or operational data corresponding to the operation of the pump 800. Examples of medical data represented by the waveform 1002 include positioning signals and motor currents. The waveform 1002, such as a motor current waveform, may provide a history, representation, and / or diagram of the motor current over a period of time (e.g., 10 seconds). In this manner, the image 1000 includes motor current data (and other data) associated with the pump 800 over a 10 second period. Thus, in one embodiment, the data module 102 constantly monitors the video stream output from the appliance controller 900, but only periodically captures images such as the image 1000. The data module 102 then transmits the image 1000 to another device, such as the server 116, which converts the represented waveform 1002 into medical and / or operational data, for example using OCR. For example, if the waveform 1002 represents 10 seconds of medical data, the data module 102 may capture successive images 1000 every 10 seconds (at 10 second intervals) so that there are no gaps in the data provided to the server 116. Processes 1300 and 1400, discussed below in connection with Figures 13 and 14, respectively, describe exemplary methods of extracting data from an image and determining the validity of the extracted data.

[0065] In one aspect, the server 116 masks certain portions of the image 1000 before extracting data using the OCR unit 630 or equivalent. FIG. 11 illustrates an example image 1100, configured in accordance with one or more aspects of the present disclosure. The image 1100 is a masked version of the image 1000 in which certain portions of the image 1000 have been removed. For example, all portions of the image 1000 are removed except for the alarm and serial number portion 1102, the performance level portion 1104, and the flow level portion 1106. After generating the image 1100, the server 116 performs image processing to clarify and expand the alarm and serial number portion 1102, the performance level portion 1104, and the flow rate portion 1106.

[0066] FIG. 12 illustrates an example image 1200, configured in accordance with one or more aspects of the present disclosure. Image 1200 is a processed version of image 1100 to facilitate extraction of data using OCR unit 630. In one aspect, alarm and serial number portion 1102 may be processed into serial number portion 1202 and alarm portion 1204. Serial number portion 1202 includes a specific number of digits that identifies the medical device 624 currently being monitored and may be expanded to facilitate OCR. For example, serial number portion 1202 includes six digits. Alarm portion 1204 may indicate a type of alarm that may be occurring on medical device 624. For example, alarm portion 1204 includes color pixels that indicate a severity of an alarm that may be occurring on medical device 624. Example colors for alarm portion 1204 include red, yellow, and green. In some aspects, performance level portion 1206 indicates a performance level of pump 800 and includes three letters. Examples of characters in the performance level portion 1206 may include "OFF", "P-0", "P-1", "P-2", "P-3", "P-4", "P-5", "P-6", "P-7", "P-8", and "P-9". The performance level portion 1206 may be an expanded version of the performance level portion 1104. In another aspect, the flow rate portion 1106 may be processed into a current flow rate portion 1208, a maximum flow rate portion 1210, and a minimum flow rate portion 1212. The current flow rate portion 1208 indicates the current flow rate of the pump 800 in units of liters per minute. Correspondingly, the maximum flow rate portion 1210 and the minimum flow rate portion 1212 may each indicate a range of flow rates of the pump 800 and may be expanded to facilitate OCR. The current flow rate portion 1208, the maximum flow rate portion 1210, and the minimum flow rate portion 1212 each include three characters ranging from "0.0" to "9.9".

[0067] A process 1300 for extracting data from an image is shown in Figure 13. The process 1300 begins with receiving a first image representing data from a medical device 624 at step 1302. For example, the remote link 102 captures an image 1000 using the image capturer 628, and the server 116 receives the image 1000 from the remote link 102.

[0068] The process 1300 continues with masking the first portion of the first image at step 1304. For example, the server 116 uses an image mask to mask portions of the image 1000 that are not sent to the OCR unit 630 for data extraction. Masking selected portions of the image can improve the efficiency of image processing because only the unmasked selected portions of the image are sent to the OCR unit 630 or the DSP unit 634. Masking selected portions of the image can result in less data being transmitted between the server 116 and the OCR unit 630 and the DSP unit 634, and the OCR unit 630 and the DSP unit 634 require less processing to extract data from the image. In one aspect, the server 116 can generate the image 1100 by removing certain portions of the image 1000 from the image 1000 using an image mask. For example, the server 116 generates the image 1100 by using an image mask to strip out all portions of the image 1000 except the alarm and serial number portion 1102, the performance level portion 1104, and the flow level portion 1106. In another aspect, the server 116 may select a different mask that corresponds to a feature of the image 1000. For example, the server 116 may select a different mask based on the size of the image 1000 or the GUI version that corresponds to the image 1000. For example, the server 116 may select a mask based on the software version of the remote link 102. In some aspects, the server 116 may select a mask based on the type of display screen 902 being used. For example, if the image displayed on the display screen 902 is not an appropriate image for the first mask selected by the server 116, the server 116 may determine that the first mask used is not an appropriate mask for the image 1000 and select a different mask based on the image currently displayed on the display screen 902. In one aspect, the server 116 may wait until an appropriate image is displayed on the display screen 902 before masking a portion of the image 1000. In another aspect, the server 116 may select the mask based on the amount of data to be extracted from the image 1000 .

[0069] Process 1300 continues with generating a second image using the remaining portions of the first image at step 1306. For example, server 116 performs image processing to generate image 1200 by clarifying and enlarging alarm and serial number portion 1102, performance level portion 1104, and flow rate portion 1106. In one aspect, server 116 may generate serial number portion 1202 and alarm portion 1204 from serial number portion 1102, performance level portion 1206 from performance level portion 1104, and current flow rate portion 1208, maximum flow rate portion 1210, and minimum flow rate portion 1212 from flow rate portion 1106.

[0070] The process 1300 ends with extracting data from the second image using optical character recognition at step 1308. For example, the serial number of the medical device 624, the type of alarm currently being indicated, the performance level of the pump 800, and the flow rate are extracted from the image 1200 using the OCR unit 630. In one aspect, the OCR unit 630 may select pixels from the second image to determine the alarm severity from the alarm portion 1204. For example, the OCR unit 630 may determine the color of the pixel and determine the alarm severity based on the color of the pixel. In some aspects, the OCR unit 630 may select two different pixels from the second image to determine the alarm severity from the alarm portion 1204. For example, the storage 120 stores a database of alarm types, alarm severities, and corresponding alarm colors. The server 116 may access the database stored in the storage 120 and determine the alarm type and severity associated with the color of one or more pixels from the alarm portion 1204. In another aspect, the OCR unit 630 may select a first pixel at a first time and a second pixel at a second time. For example, if the image 1000 is defective when received by the server 116, the server 116 cannot determine the color of the pixel from the second image at the first time. The server 116 receives another image 1000 to determine the color of another pixel from the second image at the second time. In another aspect, the server 116 determines the alarm severity to be the same as the severity of the previous alarm if the server 116 cannot determine the color of the pixel from the two pixels. In another aspect, the process 1400 described below may be used to validate the extracted data from the second image.

[0071] A process 1400 for determining the validity of data from an image is shown in Figure 14. The process 1400 begins with extracting first data from a first portion of the image using optical character recognition at step 1402. For example, the serial number of the medical device 624 is extracted from the serial number portion 1202. In one aspect, the extraction of the first data from the first portion of the image may be performed using the process 1300 described above.

[0072] The process 1400 continues with comparing the first data to reference data at step 1404. In one aspect, the reference data may include a specific number of letters and / or numbers representing a standard format in which the first data may be represented. For example, the extracted serial number of the medical device 624 is compared to possible serial numbers stored in the document data type storage 120. Further examples of comparing data to reference data are described in U.S. Patent No. 9,002,083, entitled "System, Method, and Software for Optical Device Recognition Association," the entire contents of which are incorporated herein by reference.

[0073] The process 1400 continues at step 1406 by determining the validity of the first data based on the comparison. For example, if the extracted serial number of the medical device 624 does not match a standard format for serial numbers, for example, consisting of a certain number of letters and / or numbers, the extracted serial number is not valid. In one aspect, if the extracted serial number does not include six digits and the standard format for serial numbers is six digits, the extracted serial number is not valid. In another aspect, step 1406 is repeated a certain number of times before making a final determination. For example, if three attempts are required to validate the first data, the first data is determined to be valid if the comparison results match three times. If one of the comparison results does not match during the three attempts, the first data is determined to be invalid.

[0074] In response to determining that the first data is valid based on the comparison, the process 1400 proceeds to step 1408. At step 1408, the process 1400 continues by extracting second data from a second portion of the second image using optical character recognition. For example, a performance level of the pump 800 is extracted from the performance level portion 1206. As described in connection with FIG. 12, example characters in the performance level portion 1206 may include "OFF", "P-0", "P-1", "P-2", "P-3", "P-4", "P-5", "P-6", "P-7", "P-8", and "P-9". In one aspect, the process 1400 may proceed to step 1402 until all data from each portion of the image 1200 has been extracted.

[0075] In response to determining that the first data is not valid based on the comparison, the process 1400 proceeds to step 1410. At step 1410, the process 1400 continues by broadcasting a signal indicating that the first data is not valid. For example, the server 116 notifies the remote link 102 that the image 1000 generated invalid first data.

[0076] The process 1400 ends with receiving a third image representative of the data from the medical device at step 1412. For example, the remote link 102 may capture another image similar to 1000 using the image capturer 628, and the server 116 may receive the similar image from the remote link 102. In one aspect, the process 1400 may continue at step 1402 until all data from each portion of the image 1200 has been extracted.

[0077] 15 is a schematic diagram of a remote link architecture 1500. The remote link architecture 1500 includes a remote link 102, a client device 104, a cloud 1502, a PKI provider 1510, an external sensor 1508, and a medical device 624. The cloud 1502 may include a network 1504 and a server 1506. The medical device 624 may include an internal sensor 626.

[0078] The remote link 102 may be incorporated into medical equipment 624 monitoring a patient at a hospital, clinic, the patient's home, or another location. The remote link 102 may capture images and deliver a video stream from the display of the medical equipment 624 and transmit the images and video to a network 1504. The remote link architecture 1500 may include multiple remote links 102. The remote link 102 communicates with other portions of the remote link architecture 1500 via the network 1504.

[0079] The medical device 624 may be a medical device monitoring a patient in a hospital, a clinic, the patient's home, or another location. The medical device 624 includes a sensor 626 that may be measuring and recording health signals from the patient. The sensor 626 may be a pressure sensor, a temperature sensor, a flow sensor, a voltage sensor, a current sensor, a light sensor, or an audio sensor. The external sensor 1508 may also be a pressure sensor, a temperature sensor, a flow sensor, a voltage sensor, a current sensor, a light sensor, or an audio sensor communicatively coupled to the remote link 102.

[0080] The client device 104 may be a personal computer, tablet, or mobile device with an Internet connection. A medical practitioner using the client device 104 may wish to obtain information from one or more remote links 102. Images captured by the remote links 102 may be accessed by the client device 104. In addition, if the medical practitioner wishes to view a live video stream of a medical device 624 with an integrated remote link 102, the client device may display the video stream. The remote link architecture 1500 may include multiple client devices 104. One client device 104 may access multiple remote links 102, as long as the client device has access to the remote links 102.

[0081] The server 1506 may include a mechanism for clients to view information, data, and video streams from one or more remote links 102. The server 1506 may push messages to a group of client devices 104. When a client device 104 connects to the server 1506, the client device 104 registers with the server 1506 for messages for any of the one or more remote links 102. The server 1506 will receive messages applicable to one or more remote links 102. The messages, along with associated data, are broadcast from those remote links 102 to all connected client devices 104 for updates. The cloud 1502 represents a network 1504 of Internet-based devices and connections, such as servers 1506, storage, applications, etc.

[0082] The PKI provider 1510 may include a mechanism for generating a public-private key pair associated with the remote link 102. The private key may be loaded into the remote link 102 at the time of manufacture or distribution of the remote link 102. The PKI provider 1510 may store public-private key pairs associated with multiple remote links 102. For a particular data module, the PKI provider 1510 may be the manufacturer of the data module, e.g., the remote link 102. The manufacturer may preload the public / private key pair into the data module at the time of manufacture. The manufacturer may also provide a copy of the public / private key pair, at the same time or at another time, to the server 1506, which may be controlled and / or owned by the medical device 624 and / or the monitor and / or operator of the remote link 102 or sensor 1508. In another embodiment, the PKI provider 1510 may be the operator of the remote link 102, e.g., a hospital, who may load the public / private key pair into the remote link via a data port or data network connection. In yet another configuration, a data module, such as the remote link 102, may be configured to remotely access the PKI provider 1510 over a data network when the data module is connected to the data network, such as upon initial setup, device startup, or registration. In some configurations, the PKI provider 1510 is included as part of the cloud 1502. In certain implementations, the server 1506 includes the PKI provider 1510, such as including functionality that allows for generation of public / private key pairs.

[0083] A process 1600 for authenticating a connection between a remote link 102 and a server 1206 during an online mode is shown in Figure 16. The process 1600 begins with connecting a client device 104 to the cloud 1502 at step 1602. For example, a user may use the client device 104 to log in information to connect to a web user interface of the cloud 1502.

[0084] The process 1600 continues at step 1604 by connecting the remote link 102 to the cloud 1502. For example, the remote link 102 may confirm the connection to the cloud 1502 by sending a message to the cloud 1502 and receiving a message from the cloud 1502.

[0085] The process 1600 continues with requesting that the remote link 102 enter a maintenance mode at step 1606. For example, a user may use the client device 104 to send a request to the cloud 1502 to enter a maintenance mode on the remote link. The maintenance mode would allow the user to access the internal settings and stored data of the remote link 102.

[0086] The process 1600 continues with sending a request from the cloud 1502 to the remote link 102 to enter maintenance mode at step 1608. For example, the server 1506 may send a message to the remote link 102 using the network 1504. The message may include a request for the remote link 102 to enter maintenance mode. The "enter maintenance mode" message may include a timestamp based on a time maintained by the cloud 1502, where the timestamp corresponds to the time the "enter maintenance mode" message is sent to the remote link 102, which corresponds to the time the cloud 1502 calculates the password at step 1614, or any other time specified by the cloud 1502. The time may include TAI, UTC, and / or UNIX time.

[0087] Process 1600 continues with placing the remote link 102 in a maintenance mode at step 1610. For example, when the remote link 102 receives a request to enter a maintenance mode, the remote link 102 may change its operating mode to the maintenance mode.

[0088] The process 1600 continues with calculating a password at the remote link 102 at step 1612. For example, the RLM device 102, e.g., the remote link 102, may generate a password or authentication key using a password generator or a pseudo-random number generator. The RLM device 102 receives a timestamp from the cloud 1502 via the "Maintenance Mode Start" message. The RLM device 102 generates a password or authentication key using at least the timestamp and its secret key as inputs to the password generator or pseudo-random number generator. The password may be alphanumeric. The password length may be 4 characters, 8 characters, 10 characters, 12 characters, 20 characters, or more. The authentication key may include a 32-bit, 64-bit, 128-bit, 512-bit, 1024-bit, 2048-bit, or more authentication key. The password generation or pseudo-random number generation may be performed according to the requirements specified by, for example, RFC4086 and / or RFC6328.

[0089] The process 1600 continues with calculating the password in the cloud 1502 at step 1614. The cloud 1502 may include a server that calculates the password, such as the server 1506 of FIG. 15. The server 1506 may be loaded with public / private keys. The server 1506 may receive and store public / private key pairs from the PKI provider 1510 for multiple RLM devices 102. In one embodiment, the server 1506 uses a timestamp and a private key associated with a particular RLM device 102 to generate a password or authentication key that allows authenticated access to that particular RLM device 102.

[0090] The process 1600 concludes at step 1616 by displaying the generated password on a user interface of the cloud 1502. Additionally or alternatively, the cloud 1502 may store the generated password, for example, on the server 1506. For example, once the password is generated on the server 1506, the user may use the client device 104 to receive the password from the server 1506 using the network 1504. In certain implementations, the user or actor may not verify the generated password or authentication key, and the cloud 1502 may provide the generated password or generated authentication key to the client device 104 so that the client device 104 can authenticate itself to a data module, for example, the remote link 102. When a password is used, the client device 104 may present the password to the data module so that the data module can compare the data module's password to the presented password. If the passwords match, the data module allows access by the client device 104. The client device 104 and the data module, e.g., the remote link 102, may set up a protected Secure Sockets Layer (SSL) or TLS session and / or a VPN connection to protect the password from interception when requesting access and / or when requesting maintenance mode. Alternatively, the client device 104 may present an authentication key to the data module when requesting access. As another alternative, the client device 104 and the data module may use a challenge-response protocol or other cryptographic authentication scheme based on an authentication key or password to allow the data module to authenticate the client device 104 for subsequent access to the data module.

[0091] A process 1700 for authenticating a connection between a remote link 102 and a server 1506 during an offline mode is shown in Figure 17. The process 1700 begins with connecting a client device 104 to the cloud 1502 at step 1702. For example, a user may use the client device 104 to log in information to connect to a web user interface of the cloud 1502.

[0092] The process 1700 continues with requesting that the remote link 102 enter a maintenance mode at step 1704. For example, a user may use the client device 104 to send a request to the cloud 1502 to enter a maintenance mode on the remote link. The maintenance mode would allow the user to access the internal settings and stored data of the remote link 102.

[0093] The process 1700 continues with computing a password in the cloud 1502 at step 1706. For example, the server 1506 may generate a password or authentication key using a secret key associated with the remote link 102 and a time determined by the server 1506, e.g., the current time, as input to a password generator or pseudo-random number generator. The password may be alphanumeric. The password length may be 4 characters, 8 characters, 10 characters, 12 characters, 20 characters, or longer. The password generation or pseudo-random number generation may be performed according to requirements specified by, for example, RFC4086 and / or RFC6328. In the offline mode, a timestamp may be based on a time maintained by the cloud 1502, where the timestamp corresponds to the time a “start maintenance mode” message is initiated by a user or actor, which corresponds to the time the cloud 1502 computes the password at step 1706, or any other time specified by the cloud 1502. The time may be by rounding to establish a time interval where the cloud 1502 and the RLM device 102 have overlapping and / or synchronized time intervals, whereby the times determined separately by the cloud 1502 and the RLM device 102 are the same. In this way, it is ensured that the input time and secret key used to calculate the password or authentication key will be the same, and that the password or authentication key calculated at the cloud 1502 and the RLM device 102 will be the same. The time interval may be adjustable to set a lower or upper limit for an acceptable synchronization accuracy. For example, the time interval may be 1 second, 10 seconds, 30 seconds, 1 minute, 5 minutes, 10 minutes, or more. The longer the time interval, the more likely it is that the time determined by the cloud 1502 will be the same as the time used by the RLM device 102, which corresponds to a clock timing misalignment between the cloud 1502 and the RLM device 102. This synchronization method may also be used within the online mode described according to FIG. 16 in addition to, or as an alternative to, including a timestamp in the “start maintenance mode” message.The time may include TAI, UTC, and / or UNIX time.

[0094] Process 1700 continues at step 1708 with displaying the generated password on a user interface of cloud 1502. Additionally or alternatively, cloud 1502 may store the generated password, for example, on server 1506. Once the password is generated on server 1506, the user may use client device 104 to receive the password from server 1506 using network 1504.

[0095] Process 1700 continues with placing the remote link 102 in a maintenance mode at step 1710. For example, when the remote link 102 receives a request to enter a maintenance mode, the remote link 102 may change its operating mode to the maintenance mode.

[0096] The process 1700 finally calculates a password at the remote link 102 at step 1712. As previously mentioned, the password or authentication key may be generated based on input of at least a timestamp and a secret key of the particular RLM device 102 to a password generator or pseudo-random number generator that outputs a password or authentication key associated with the particular RLM device 102. In an offline mode, the timestamp may be based on a time maintained by the RLM device 102, where the timestamp corresponds to the time when the "enter maintenance mode" message is initiated by a user or actor, which corresponds to the time when the RLM device 102 calculates the password at step 1712, or any other time specified by the RLM device 102. The time may be by rounding to establish a time interval where the cloud 1502 and the RLM device 102 have overlapping and / or synchronized time intervals, thereby establishing a time interval where the times determined separately by the cloud 1502 and the RLM device 102 are the same. In this way, the input time and secret key used to calculate the password or authentication key at both the cloud 1502 and the RLM device 102 will be the same. The time interval may be adjustable to set a lower or upper limit for acceptable synchronization accuracy. For example, the time interval may be 1 second, 10 seconds, 30 seconds, 1 minute, 5 minutes, 10 minutes, or more. The longer the time interval, the more likely it is that the time determined by the cloud 1502 will be the same as the time used by the RLM device 102, which corresponds to a clock timing misalignment between the cloud 1502 and the RLM device 102. This synchronization method may also be used in the online mode described according to FIG. 16 in addition to or as an alternative to including a timestamp in the “maintenance mode start” message. The time may include TAI, UTC, and / or UNIX time.

[0097] A process 1800 for authenticating a connection between a remote link (or data module) 102 and a server 1506 is shown in Figure 18. The process 1800 begins by assigning the private key of a public-private key pair associated with the remote link 102 at step 1802. In one aspect, the remote link 102 may receive pressure data, temperature data, flow data, voltage data, current data, light data, or audio data from the medical device 624. In another aspect, the remote link 102 may receive data from an external sensor 1508.

[0098] The process 1800 continues at step 1804 with storing the private key in the data module 102. For example, the remote link 102 may have the private key loaded into the remote link 102 at the time of manufacture or distribution of the remote link 102.

[0099] The process 1800 continues with storing the private key at the server 1506 at step 1806. For example, the private key may be stored by the server after the private key is loaded into a data module. The server 1506 may have private keys for multiple remote links 102 stored in internal storage.

[0100] The process 1800 continues at step 1808 with generating a request at the client device 104 for access to the data module 102. For example, the client device 104 may include a user interface configured to display data and receive user input. A user may generate the request for access to the data module 102 using the user interface. In one aspect, the request for access to the data module 102 may include a request for the remote link 102 to enter a maintenance mode.

[0101] The process 1800 continues at step 1810 with sending a request to the server 1506 for access to the remote link 102. For example, a user may send the request to the server 1506 using a user interface.

[0102] The process 1800 continues at step 1812 with receiving a request from the client device 104 at the server 1506 for access to the remote link 102. For example, the server may receive the request using the network 1504.

[0103] The process 1800 continues with generating, at step 1814, an authentication key at the remote link 102 used to allow authenticated access to the remote link 102 based on at least the private key and the time. For example, the remote link 102 may generate the authentication key using the PKI provider 1510 based on the private key and the time. In another aspect, the authentication key may be a one-time authentication key. For example, if the remote link 102 generates the authentication key, the authentication key may be used only once to access the remote link 102. In one aspect, the instructions may include a time. The time may be determined by the server 1506 or may be determined independently by the remote link 102. The time determined by the remote link 102 may be synchronized with the time determined by the server 1506. In one aspect, the times are synchronized by rounding the time determined by the remote link 102 to a time interval and rounding the time determined by the server 1506 to the time interval so that the determined times are the same. For example, if the time interval is 5 minutes and the time determined by the remote link 102 is 09:04, the time will be rounded to 09:05. The time interval may be adjustable to set a lower or upper limit on the acceptable synchronization accuracy. In one aspect, the time includes TAI (International Atomic Time), UTC (Coordinated Universal Time), or UNIX time.

[0104] The process 1800 continues at step 1816 with generating an authentication key at the server 1506 based on the secret key and the time. For example, the server 1506 may generate the authentication key based on the secret key and the time. In another aspect, the authentication key may be a one-time authentication key. For example, if the server 1506 generates an authentication key, the authentication key may be used only once to access the remote link 102.

[0105] The process 1800 continues at step 1818 with the server 1506 receiving an indication from the remote link 102 that the authentication key generated at the server 1506 has been entered. For example, the server 1506 may transmit the authentication key generated at the server 1506 to the remote link 102 using the network 1504, a user may enter the authentication key generated at the server 1506 into the remote link 102, and the remote link 102 may send an indication to the server 1506 indicating that the authentication key has been entered. The remote link 102 may include a user interface configured to display data and receive user input. The user may enter the authentication key generated at the server 1506 using the user interface of the remote link 102.

[0106] The process 1800 finally determines, at step 1820, whether the authentication key generated at the remote link 102 and the authentication key generated at the server 1506 match. If the authentication key generated at the remote link 102 matches the authentication key generated at the server 1506, authenticated access is allowed at step 1822. Otherwise, if the authentication key generated at the remote link 102 does not match the authentication key generated at the server 1506, access is denied at step 1824. For example, if the authentication key generated at the remote link 102 does not match the authentication key generated at the server 1506, the remote link 102 may display a message indicating authentication failure. In one aspect, the remote link 102 may authenticate the client device 104 using a challenge-response protocol.

[0107] The process 1800 allows a user to securely connect to a remote link 102 connected to a medical device 624 and access a maintenance mode of the remote link 102. The user may then modify settings and procedures of the remote link 102. For example, the user may change network 1504 connection settings. If authentication is successful, the remote link 102 may transmit data to the client device 104. The process 1800 allows a user to securely connect to a remote link 102 connected to a medical device 624 and access data collected by the remote link 102 from the medical device.

[0108] A process 1900 for authenticating a connection between a remote link (or data module) 102 and a server 1506 is shown in Figure 19. The process 1900 begins with assigning the private key of a public-private key pair associated with the remote link 102 in step 1902.

[0109] The process 1900 continues at step 1904 with storing the private key in the data module 102. For example, the remote link 102 may have the private key loaded into the remote link 102 at the time of manufacture or distribution of the remote link 102.

[0110] The process 1900 continues at step 1906 with storing the private key at the server 1506. For example, the private key may be stored by the server after the private key is loaded into a data module. The server 1506 may have private keys for multiple remote links 102 stored in internal storage.

[0111] The process 1900 continues at step 1908 with receiving data from the medical device 624 at the remote link 102. For example, the remote link 102 may receive pressure data, temperature data, flow data, voltage data, current data, light data, or audio data from the medical device 624. In another aspect, the remote link 102 may receive data from an external sensor 1508.

[0112] The process 1900 continues at step 1910 with generating a request at the client device 104 for access to the data module 102. For example, the client device 104 may include a user interface configured to display data and receive user input. A user may generate the request for access to the data module 102 using the user interface. In one aspect, the request for access to the data module 102 may include a request for the remote link 102 to enter a maintenance mode.

[0113] The process 1900 continues at step 1912 with sending a request to the server 1506 for access to the remote link 102. For example, a user may send the request to the server 1506 using a user interface.

[0114] The process 1900 continues at step 1914 with receiving a request from the client device 104 at the server 1506 for access to the remote link 102. For example, the server may receive the request using the network 1504.

[0115] The process 1900 continues at step 1916 with generating an authentication key at the remote link 102 to be used to allow authenticated access to the remote link 102 based on at least the private key and the time. For example, the remote link 102 may generate the authentication key using the PKI provider 1510 based on the private key and the time. In another aspect, the authentication key may be a one-time authentication key. For example, if the remote link 102 generates the authentication key, the authentication key may be used only once to access the remote link 102. In one aspect, the instructions may include a time. The time may be determined by the server 1506 or may be determined independently by the remote link 102. The time determined by the remote link 102 may be synchronized with the time determined by the server 1506. In one aspect, the times are synchronized by rounding the time determined by the remote link 102 to a time interval and rounding the time determined by the server 1506 to the time interval so that the determined times are the same. For example, if the time interval is 5 minutes and the time determined by the remote link 102 is 09:04, the time will be rounded to 09:05. The time interval may be adjustable to set a lower or upper limit on the acceptable synchronization accuracy. In one aspect, the time includes TAI (International Atomic Time), UTC (Coordinated Universal Time), or UNIX time.

[0116] The process 1900 continues at step 1918 with generating an authentication key at the server 1506 based on the secret key and the time. For example, the server 1506 may generate the authentication key based on the secret key and the time. In another aspect, the authentication key may be a one-time authentication key. For example, if the server 1506 generates an authentication key, the authentication key may be used only once to access the remote link 102.

[0117] The process 1900 continues at step 1920 with the server 1506 receiving an indication from the remote link 102 that the authentication key generated at the server 1506 has been entered. For example, the server 1506 may transmit the authentication key generated at the server 1506 to the remote link 102 using the network 1504, a user may enter the authentication key generated at the server 1506 into the remote link 102, and the remote link 102 may send an indication to the server 1506 indicating that the authentication key has been entered. The remote link 102 may include a user interface configured to display data and receive user input. The user may enter the authentication key generated at the server 1506 using the user interface of the remote link 102.

[0118] The process 1900 concludes with step 1922, where it determines whether the authentication key generated by the remote link 102 matches the authentication key generated by the server 1506. If the authentication key generated by the remote link 102 does not match the authentication key generated by the server 1506, access is denied at step 1924. For example, if the authentication key generated by the remote link 102 does not match the authentication key generated by the server 1506, the remote link 102 may display a message indicating authentication failure.

[0119] Otherwise, if the authentication key generated at the remote link 102 matches the authentication key generated at the server 1506, the remote link 102 may transmit the data to the client device 104 at step 1926. The process 1900 allows a user to securely connect to a remote link 102 connected to a medical device 624 and access data collected by the remote link 102 from the medical device.

[0120] Although a percutaneous heart pump is described herein, it will be understood that any other medical device may be used in conjunction with the present disclosure. Additionally, while Figures 8 and 9 show a media device configuration in which the controller 900 is separate from the pump 800, one of ordinary skill in the art will readily appreciate that the medical device may be configured such that the controller and pump (or other elements) are integrated within the same housing.

[0121] Other objects, advantages and aspects of the various aspects of the present invention will be apparent to those skilled in the art of the present invention and are within the scope of this description and the accompanying drawings. For example, and without limitation, structural or functional elements may be rearranged consistent with the present invention. Similarly, the principles according to the present invention may be applied to other examples that are within the scope of the present invention, even if not specifically described in detail herein.

Claims

1. a data module including a user interface configured to display data and receive user input, the data module being communicatively coupled to the server via a data network; storing a private key of a public-private key pair associated with the data module; Receive data from medical devices, generating an authentication key based on at least the private key and a time; receiving an authentication key generated by the server; and In response to determining that the authentication key generated by the data module and the authentication key generated by the server match, granting the user authenticated access to the data module. A data module configured as follows:

2. 2. The data module of claim 1, wherein the data module is further configured to, in response to determining that the authentication key generated by the data module and the authentication key generated by the server do not match, display a message indicating authentication failure.

3. The data module of claim 1 , wherein the data module is configured to grant authenticated access using a challenge-response protocol.

4. The data module of claim 1 , wherein the data module is configured to transmit data to the client device upon successful authentication.

5. A data module according to any preceding claim, wherein the time is determined by the data module.

6. 6. The data module of claim 5, wherein the time is determined by rounding the time maintained by the data module to a time interval such that the time determined by the data module is the same as a time separately determined by the server and used to generate an authentication key.

7. 7. The data module of claim 6, wherein the time interval is adjustable to set a lower or upper limit on an acceptable synchronization accuracy.

8. The data module of any one of claims 1 to 5, wherein the time includes at least one of TAI, UTC, and UNIX time.

9. 6. The data module according to claim 1, wherein said time is the current time.

10. The data module according to any one of claims 1 to 9, wherein the authentication key is a one-time authentication key.

11. 11. The data module of claim 10, wherein the authentication key expires after a period of time.

12. A data module according to any preceding claim, wherein the private key is loaded into the data module during at least one of the manufacture and distribution of the data module.

Images