Decentralized secure distribution of medical device software updates

Abstract

In one exemplary mode, a medical system includes: a first medical device including an interface connected to a network of a plurality of medical devices; and a processor running medical device software, running a first medical device software update agent to receive identity information about a first medical device from the medical device software, sending the identity information to a cloud medical device software update agent via the interface and at least one second medical device software update agent installed in at least one second medical device of the plurality of medical devices, and sending the identity information to the cloud medical device software update agent via the at least one second medical device software update agent, a medical device software update and a digital signature made by a manufacturer of the first medical device are received from the cloud medical device software update agent, the received medical device software update is authenticated based on the digital signature, and the authenticated medical device software update is installed.

Description

[0001] Related application information

[0002] This application claims the benefit of U.S. Provisional Patent Application Ser. No. 63 / 612,525, filed Dec. 20, 2023, by Ravuna et al. and entitled "Decentralized secure distribution of software updates to medical devices", the disclosure of which is hereby incorporated herein by reference. Technical Field

[0003] This disclosure relates to medical systems and, in particular but not exclusively, to the distribution of software updates for medical devices. Background Art

[0004] Software updates are critical for digital and cybersecurity and also provide other benefits, including fixing security vulnerabilities, patching computer bugs, and adding new features to devices. Hackers may exploit software vulnerabilities, for example, by writing code targeted at the vulnerability.

[0005] Updating software and operating systems helps prevent hacking, protects data, and ensures that software performs according to the latest operating methods, which is particularly important for sensitive data and medical devices running life-critical or other applications. Brief Description of the Drawings

[0006] The present disclosure will be understood from the following detailed description in conjunction with the accompanying drawings, in which:

[0007] Figure 1 is a block diagram of a computer system in a medical facility constructed and operated in accordance with an exemplary mode of the present disclosure;

[0008] Figure 2 is a block diagram of another computer system in a medical facility constructed and operated in accordance with another exemplary mode of the present disclosure;

[0009] Figure 3 is a block diagram of another computer system in a medical facility constructed and operated in accordance with yet another exemplary mode of the present disclosure;

[0010] Figure 4 is Figure 1 a block diagram of a medical device in the system of;

[0011] Figure 5 is Figure 4 a block diagram of a memory and stored tables in the device of;

[0012] Figures 6 to 9 is a view of a routing table showing the routes forFigure 1 Generation of a routing table in a system;

[0013] Figure 10 is a flowchart of steps in a method including generating a routing table used by a system in Figure 1 ;

[0014] Figure 11 is a flowchart of steps in a method including providing a software update for a device in Figure 4 ;

[0015] Figure 12 is a flowchart of steps in a method including receiving and processing a file in a device in Figure 4 ;

[0016] Figure 13 is a flowchart of steps in a method including receiving and processing a log in a device in Figure 4 ; and

[0017] Figure 14 is a flowchart of steps in a method including receiving and processing a log by a cloud proxy in a system in Figure 1 ; DETAILED DESCRIPTION

[0018] Overview

[0019] As previously mentioned, it is important to update device software as needed to maintain safety, security, and effectiveness throughout the product lifecycle. This is particularly important for medical devices. According to the "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" released by the FDA on September 27, 2023, timeliness of updates and patchability are security objectives evaluated by the FDA during inspections of medical devices.

[0020] Many medical devices in healthcare facilities such as hospitals are not directly connected to the internet for safety reasons and / or, for example, due to lack of device capabilities. As a result, such devices cannot receive relevant cybersecurity and other updates in a timely manner, if any. This is particularly critical for cybersecurity updates, as these updates need to be distributed quickly. Delays in distributing cybersecurity updates increase the risk of zero-day attacks.

[0021] Accordingly, an exemplary mode of the present disclosure addresses some of these drawbacks by providing a system in which a medical device installed in a medical facility has an agent that facilitates the transfer of software updates from one or more cloud software update agents to the medical device. Even if not all medical devices are connected to the Internet, one or more of the medical devices can be connected to the Internet to receive software updates from the cloud software update agent on behalf of the medical devices that are not directly connected to the Internet. However, the medical devices that are not directly connected to the Internet are capable of (directly or indirectly) connecting to a medical device that has an Internet connection, and the latter type of medical device is connected to the Internet via a suitable communication link (such as a USB connection and / or an Ethernet connection). The received software updates can then be distributed via the network of the agent in the medical device installed in the medical facility. In this way, the software updates can be forwarded to all the connected medical devices in the medical facility to ensure that each device has updated its medical software. The cloud software agent can provide software updates for different manufacturers of the medical devices installed in the medical facility. In some exemplary modes, the cloud software agent can include an agent for each manufacturer of the medical devices installed in the medical facility. For example, the cloud software agent for manufacturer A can be connected to the medical devices of manufacturer A in the medical facility, and the cloud software agent for manufacturer B can be connected to the medical devices of manufacturer B in the medical facility.

[0022] The distribution of software updates can include a zero-trust approach in which the medical devices installed in the medical facility do not need to trust each other, which is particularly important in the case where the medical devices are produced by different manufacturers. The above method can also use the existing data connections between the devices.

[0023] The agent installed in the medical device executes a discovery method to discover the medical devices and cloud agents installed in the medical facility, and the topology of the connections between the medical devices and the cloud agents, as described in the disclosed exemplary mode. The discovery method generates a routing table in each of the medical devices and cloud agents, and allows files such as software updates to be forwarded from the cloud agent to the relevant medical device, and allows software update logs and other log files to be forwarded from the medical device to the cloud agent. The discovery method can be applied to a basic topology or a more complex mesh topology, such as including loops, as described in the disclosed exemplary mode.

[0024] An agent operating in a medical device may provide received software updates to be installed in the medical device and forward other received software updates to other medical devices according to the destination addresses of the corresponding received software updates. An agent operating in a medical device may receive logs from the medical device or from other medical devices to forward the logs to a cloud agent via one or more medical devices installed in a healthcare facility. In some cases, when a medical device is directly connected to the Internet, the medical device may forward the logs to the cloud agent via the Internet connection.

[0025] Each agent may maintain and store a file delivery table (providing an indication of received files for delivery, such as file names, and corresponding destination information, such as model and serial numbers), a routing table (providing identification information of medical devices that can be evaluated, such as model and serial numbers, and corresponding routing information, such as the hop count to the medical device and via which neighbor(s)), and a direct neighbor table (providing a list of direct neighbors, such as model and serial numbers, and corresponding address information, such as the IP address of the direct neighbor).

[0026] The system may include various security features described in more detail below.

[0027] In some exemplary modes, files such as software updates are signed by the manufacturer of the target medical device, for example, using the manufacturer's private key or certificate. These signatures may be checked by the medical device that is to install the software update, for example, using the public key or certificate of the relevant manufacturer. Optionally, the file may be encrypted, for example, using the public key of the corresponding medical device, for decryption using the private key of the corresponding medical device.

[0028] In some exemplary modes, one or more (e.g., all) agents not installed in the target device of a software update may also check the signature of the software update to prevent the network from being flooded with unnecessary communications. If a medical device receives a file with a bad signature and an adjacent device intends to check the signature, it may be assumed that the neighbor is not working properly, for example, because the neighbor may be infected or compromised or there is a hacker mimicking the neighbor. In such a case, the medical device may automatically intercept the neighbor, for example, for a predetermined period of time.

[0029] In some exemplary modes, if an infected medical device refuses to relay a file, the cloud agent may identify the behavior based on the target medical device not confirming the installation of the software update and / or analyzing the received log files to determine which medical device did not relay the file. Then the operator may intercept the medical device that did not relay the file (e.g., remove it from the routing table) so that the file automatically reaches the destination without passing through the intercepted medical device (if there is another available path).

[0030] The log can be signed (e.g., using the private key of the medical device that generated the log) and authenticated in the cloud using the corresponding public key. A tamper-proof chip, such as a Trusted Platform Model (TPM) according to the ISO / IEC 11889 standard, can be used to store the private key of the medical device. Optionally, the manufacturing public key can be used to encrypt the log for decryption by the cloud proxy.

[0031] In some exemplary modes, the proxy can limit the size of files allowed to be received to prevent an attacker from attempting to send giant files to exhaust disk space, as the signature is typically checked at the end of the transmission. In some exemplary modes, if a file to be delivered in a medical device has been in the queue of files to be delivered for longer than a given time limit (e.g., number of days), such files can be removed from the file queue. In some exemplary modes, if the maximum queue size is reached, files to be delivered in the medical device can be removed from the queue, for example, according to the First-In-First-Out (FIFO) principle.

[0032] In some exemplary modes, if a medical device runs out of disk space, the medical device can actively send a message to its neighbors to request removal from the paths in the routing table. In some exemplary modes, if a medical device has sent too many files within a given time period, the medical device can be marked as suspicious and intercepted for a certain amount of time.

[0033] System description

[0034] Now refer to Figure 1 , which is a block diagram of a computer system 10 in a medical facility 12 constructed and operating in accordance with an exemplary mode of the present disclosure. System 10 includes a cloud medical device software update proxy 14 and a medical device 16. The medical device 16 is installed in the medical facility 12. The medical facility 12 includes a firewall 18 to provide protection to the medical device 16 from external traffic. Each medical device 16 includes a medical device software update proxy 20 and medical device software 22. The medical devices 16 in the medical facility 12 form a network and are connected via any suitable data connection 24 (e.g., USB connection and / or Ethernet connection, or any suitable combination thereof). One or more of the medical devices 16 (e.g., medical device 16-1) are configured to establish one or more corresponding Internet connections 30 with the cloud medical device software update proxy 14. The cloud medical device software update proxy 14 is configured to send software updates 26 to the medical devices 16 and receive logs 28 from the medical devices 16, as described in more detail below. The cloud medical device software update proxy 14 can include a medical device manufacturer server located in the cloud. For example, Microsoft's Azure TM IoT system or PTC's ThingWorx TMThe server is used to implement the cloud medical device software update agent 14.

[0035] Now refer to Figure 2 , which is a block diagram of another computer system 50 in the medical facility 12 constructed and operated according to another exemplary mode of the present disclosure. Except for the following differences, the computer system 50 is substantially the same as the system 10. The computer system 50 includes two cloud medical device software update agents 14 for two corresponding manufacturers. In the Figure 2 example, one of the cloud medical device software update agents 14 is for ACME, Inc. and one of the cloud medical device software update agents 14 is for Biosense Webster, Inc. The cloud medical device software update agents 14 are configured to be connected to each other via another Internet connection 30.

[0036] Now refer to Figure 3 , which is a block diagram of another computer system 60 in the medical facility 12 constructed and operated according to yet another exemplary mode of the present disclosure. Except for the following differences, the system 60 is substantially the same as the computer system 50. The two cloud medical device software update agents 14 are connected to at least one device 16 in the medical facility 12 via the Internet connection 30. In the Figure 3 example, the cloud medical device software update agent 14 of Biosense Webster, Inc. is configured to be connected to two medical devices 16-1 of Biosense Webster, Inc. in the medical facility 12 via the Internet connection 30, and the cloud medical device software update agent 14 of ACME, Inc. is configured to be connected to the medical device 16-2 of ACME, Inc. via another of the Internet connections 30.

[0037] Now refer to Figure 4 , which is Figure 1 a block diagram of one of the medical devices 16 (e.g., medical device 16-3) in the system 10 of

[0038] Interface 34 can be any suitable interface, such as an interface that supports Ethernet, an interface that supports USB, and / or an interface that supports the Internet. As previously described, one or more of the medical devices 16 are directly connected to the Internet, while other medical devices in the medical device 16 are not connected to the Internet. One or more of the medical devices 16 can be devices that do not support the Internet, that is, they cannot connect to the Internet by themselves or even process Internet Protocol (IP) packets, but are capable of sharing data on the Internet via a device that is connected to the Internet and can process IP packets. Interface 34 can be configured to share data with the cloud medical device software update agent 14 via the Internet using the Internet connection of another medical device 16.

[0039] The processor 36 is configured to run the agent 20 and the medical device software 22. The agent 20 is configured to receive the software update 26 from the cloud medical device software update agent 14 via the interface 34, optionally via one or more other medical devices 16. The received software update 26 can include one or more software updates 26 for forwarding to other medical devices 16 via the interface 34. The agent 20 can also provide the software update 26 to update the medical device software 22. The medical device software 22 can provide the log 28 to the agent 20. The agent 20 can also receive the log 28 from the agent 20 of other medical devices 16 via the interface 34. The agent 20 forwards the received log to the cloud medical device software update agent 14 via the interface 34 and optionally via one or more medical devices 16. The medical device software 22 can provide the identity information 42, such as the model number and serial number, to the agent 20 for forwarding to the cloud medical device software update agent 14, as described in more detail with reference to Figure 11 More specifically. The medical device software 22 can provide the direct neighbor identifier 44 to the agent 20, as described in more detail below with reference to Figure 5 More specifically.

[0040] The agent 20 is configured to maintain tables, including the file delivery table 46, the routing table 48, and the direct neighbor table 52. The memory 38 is configured to store the tables 46, 48, 52, which will be described in more detail below with reference to Figure 5 More specifically.

[0041] The tamper-proof chip 40 is configured to store the private key of the medical device 16. Each medical device 16 typically has its own unique private key. The use of the private key is described in more detail below in Figure 11 And Figure 13 More specifically.

[0042] In the course of implementation, some or all of these functions of processor 36 may be combined in a single physical component, or alternatively implemented using multiple physical components. These physical components may include hard-wired or programmable devices, or a combination of both. In some exemplary modes, at least some of the functions of processor 36 may be implemented by a programmable processor under the control of suitable software. The software may be downloaded electronically to the device (e.g., via a network). Alternatively or in addition, the software may be stored in a tangible non-transitory computer-readable storage medium, such as optical, magnetic, or electronic memory.

[0043] Now refer to Figure 5 , which is a Figure 4 block diagram of memory 38 and stored tables in device 16.

[0044] The file delivery table 46 includes indications 54 of one or more files received from the cloud medical device software update agent 14 for delivery to one or more of the plurality of medical devices 16 in the network, and corresponding destination information 56 for these files. The indication 54 may include a file name 58, and the destination information 56 may include the model number and serial number 62 of each corresponding entry in the file delivery table 46.

[0045] The routing table 48 includes identification information 64 of the assessable medical devices among the medical devices 16 in the network, and corresponding routing information 66 for these assessable medical devices 16. The identification information 64 may include the model number and serial number 68, and the routing information 66 may include the hop count 70 for each entry in the table and which neighbor to pass through 72. Reference Figures 6 to 10 describes the routing table 48 in more detail.

[0046] The direct neighbor table 52 includes a list 74 of one or more direct neighbors of the medical device 16 (in which the direct neighbor table 52 is stored), and address information 76 identifying the one or more direct neighbors in the network of the medical device 16. The list 74 may include the model number and serial number 78 of each entry in the direct neighbor table 52. The address information 76 may include the IP address 80 of each corresponding entry in the table. A direct neighbor is a medical device in the medical device 16 that is directly connected to the medical device 16 storing the direct neighbor table 52 without an intervening medical device 16. The direct neighbor table 52 may be populated based on the direct neighbor identification 44 received from the medical device software 22 ( Figure 4 ).

[0047] Now refer to Figures 6 to 9 , which are views of the routing table 48, showing the generation of the routing table 48 in the system 10 for Figure 1 .

[0048] Figures 6 to 9Shows device 16 (labeled as devices A to E for convenience) and cloud proxy 14. The cloud medical device software update proxy 14 is connected to device B via the Internet connection 30. Device B is directly connected to devices A and C via the data connection 24. Device D is directly connected to devices C and E via the data connection 24. And device C is directly connected to device E using one of the data connections 24.

[0049] Figure 6 Shows that each proxy 14, 20 has added its own device to its own routing table 48. The routing table lists the destination as the name of its own device, sets "via" to "local", and sets the hop count value to 0.

[0050] Figure 7 Shows that each proxy 14, 20 has added its direct neighbors to its own routing table 48 based on the direct neighbor table 52 of each proxy 14, 20. For each direct neighbor entry in the routing table 48, the destination name of the direct neighbor is given (e.g., cloud or A or B, etc.), "via" is set to "direct", and the hop count value is set to 1.

[0051] Figure 8 Shows the result of each proxy 14, 20 providing its routing table 48 to its direct neighbors and receiving the routing table 48 from its direct neighbors. The received routing table 48 is used by the receiving proxy 14, 20 to update its own routing table 48, as described in more detail now.

[0052] Each entry in the received routing table is updated such that each hop count value is incremented by 1, and "via" is set to the identity of the entity that sent the routing table. For example, if the routing table 48 is received from device A, then "via" is set to device A. Additionally, duplicate entries are removed to leave the entry with the shortest hop count, as shown in the following example.

[0053] For example, when device C receives the routing table 48 from device D, device C receives the following entries (as Figure 7 shown):

[0054] D, via local, hop count 0;

[0055] C, via direct, hop count 1; and

[0056] E, via direct, hop count 1.

[0057] The above entries are updated by the proxy 20 of device C to:

[0058] D, via D, hop count 1;

[0059] C, via D, hop count 2; and

[0060] E, via D, hop count 2.

[0061] Device C also receives routing table 48 with the following entries from device B (as Figure 7 shown):

[0062] B, via local, hop count 0;

[0063] Cloud, via direct, hop count 1;

[0064] A, via direct, hop count 1; and

[0065] C, via direct, hop count 1.

[0066] The above entries are updated by agent 20 of device C to:

[0067] B, via B, hop count 1;

[0068] Cloud, via B, hop count 2;

[0069] A, via B, hop count 2; and

[0070] C, via B, hop count 2.

[0071] Device C also receives routing table 48 with the following entries from device E (as Figure 7 shown):

[0072] E, via local, hop count 0;

[0073] D, via direct, hop count 1; and

[0074] C, via direct, hop count 1.

[0075] The above entries are updated by agent 20 of device C to:

[0076] E, via E, hop count 1;

[0077] D, via E, hop count 2; and

[0078] C, via E, hop count 2.

[0079] From Figure 7 The original entries in routing table 48 of device C are as follows:

[0080] 1. C, via local, hop count 0;

[0081] 2. B, via direct, hop count 1;

[0082] 3. D, via direct, hop count 1; and

[0083] 4. E, via direct, hop count 1.

[0084] Based on the above, the following entries are candidates for addition to the routing table 48 of device C:

[0085] 5. D, via D, hop count 1;

[0086] 6. C, via D, hop count 2;

[0087] 7. E, via D, hop count 2;

[0088] 8. B, via B, hop count 1;

[0089] 9. Cloud, via B, hop count 2;

[0090] 10. A, via B, hop count 2;

[0091] 11. C, via B, hop count 2;

[0092] 12. E, via E, hop count 1;

[0093] 13. D, via E, hop count 2; and

[0094] 14. C, via E, hop count 2.

[0095] The duplicates in the above 14 items can be analyzed as follows.

[0096] Items 1, 6, 11, and 14 provide routing information to device C. Item 1 has the smallest hop value. Therefore, item 1 is retained while items 6, 11, and 14 are removed.

[0097] Items 2 and 8 provide routing information to device B. These entries are the same, so either one can be deleted.

[0098] Items 3, 5, and 13 provide routing information to device D. Items 3 and 5 have the smallest hop values, and item 3 is via "direct". Therefore, item 3 is retained while items 5 and 13 are removed.

[0099] Items 4, 7, and 12 provide routing information to device E. Items 4 and 12 have the smallest hop values, and item 4 is via "direct". Therefore, item 4 is retained while items 7 and 12 are removed.

[0100] Item 10 provides routing information to device A and is therefore retained.

[0101] Item 9 provides routing information to the cloud and is therefore retained.

[0102] After removing the above items, the following items remain in the routing table 48 of device C:

[0103] 1. C, passing through the local area, with a hop count of 0;

[0104] 2. B, passing through directly, with a hop count of 1;

[0105] 3. D, passing through directly, with a hop count of 1;

[0106] 4. E, passing through directly, with a hop count of 1.

[0107] 9. Cloud, passing through B, with a hop count of 2; and

[0108] 10. A, passing through B, with a hop count of 2.

[0109] The above also corresponds to Figure 8 the entries shown in the routing table 48 of device C in

[0110] The updated routing table 48 is again shared with the direct neighbors and processed as above to appropriately update the "passing through" and "hop count" values, and duplicates are removed based on retaining the entry with the shortest hop count, thereby generating Figure 9 the routing table 48 shown.

[0111] In some specific implementations, the routing table 48 may need to be shared multiple times and processed as described above until a stable state is reached.

[0112] Now refer to Figure 10 , which is a flowchart 100 of the steps in a method for generating the routing table 48 used in the system 10 shown in Figure 1 . The agent 20 is configured to populate the routing table 48 (i.e., its local routing table 48) based on a list 74 of its own device and one or more direct neighbors (block 102). The agent 20 is configured to send the routing table 48 (i.e., its local routing table 48) to one or more direct neighbors (block 104) and receive the routing table 48 from the direct neighbors (block 106). The agent 20 is configured to augment the routing table 48 (i.e., its local routing table 48) based on the data included in the received routing tables (e.g., by updating the "passing through" value to the ID of the device that sent the routing table 48 and by incrementing the "hop count" value by 1 for each entry in the received routing table 48), while retaining the entry with the shortest route (i.e., the smallest hop count) based on considering the shortest route to the duplicate destination medical devices and removing the entries for one or more duplicate destination medical devices (block 108). The steps of blocks 104 to 108 may need to be repeated one or more times (arrow 110) until the routing tables 48 of each medical device 16 and the cloud medical device software update agent 14 are in a stable state (i.e., do not change).

[0113] Now refer to Figure 11 , which is a diagram for Figure 4Flowchart 200 of steps in a method of providing a software update by one of the devices 16. The terms "local agent 20" and "local medical device software 22" are used to refer to the agent 20 and the medical device software 22 running on the same local medical device 16.

[0114] The local agent 20 running in the local medical device 16 is configured to receive identity information 42 about the local medical device 16 from the local medical device software 22 (block 202). The local agent 20 is configured to send the identity information 42 via the local interface 34 and one or more other agents 20 installed in one or more other corresponding medical devices 16 to the cloud medical device software update agent 14 (block 204). The cloud medical device software update agent 14 is configured to receive the identity information 42, sign the software update 26 using the private key of the manufacturer of the local medical device 16, optionally encrypt the software update 26 using the public key of the local medical device 16, and send the software update 26 and its signature to the local medical device 16 via the other agents 20 (block 206). The local agent 20 is configured to receive the medical device software update 26 and the digital signature of the medical device software update 26 signed by the manufacturer of the local medical device 16 from the cloud medical device software update agent 14 via the other agents 20 installed in the other medical devices 16 (block 208).

[0115] The processor 36 or the agent 20 of the local medical device 16 is configured to authenticate the received medical device software update 26 based on the digital signature (e.g., the public key of the manufacturer) (block 210). When the medical device software update 26 is encrypted using the public key of the local medical device 16 by the manufacturer of the local medical device 16, the processor 36 of the medical device 16 is configured to use the private key of the local medical device 16 (e.g., stored in the tamper-proof chip 40 ( Figure 4 )) to decrypt the medical device software update 26 (block 210).

[0116] At decision block 212, the processor 36 or the agent 20 of the local medical device 16 is configured to confirm whether the software update 26 is authenticated. If the software update 26 is authenticated, the processor 36 of the local medical device 16 is configured to install the authenticated medical device software update 26 (block 214).

[0117] Once the local agent 20 sends the software update 26 to the medical device software 22, the medical device software 22 can notify the user of the local medical device 16 so that the user will select an appropriate time to install the update. Alternatively, the update can be installed automatically when the device is idle. In this case, the local medical device 16 can provide an option to cancel the update. If there is an emergency and the hospital staff immediately need the device, they can cancel the update during installation and immediately use the medical device. Alternatively, the update can be installed automatically during off-hours. In this case, the local medical device 16 can also provide an option to cancel the update.

[0118] If the processor 36 of the local medical device 16 checks the digital signature and determines that the digital signature does not authenticate the medical device software update 26 and that another medical device 16 should have checked the digital signature first, the local agent 20 can be configured to intercept the file provided by the other medical device 16 based on the other medical device's failure to recognize the lack of authentication of the medical device software update 26.

[0119] Now refer to Figure 12 , which is a flowchart 300 of the steps in a method of receiving and processing files in the local medical device 16 included in Figure 4 .

[0120] The local agent 20 of the local medical device 16 is configured to receive, via one or more other agents 20, a file (block 302) that includes one or more medical device software updates and one or more corresponding digital signatures and is destined for one or more other medical devices or for the local medical device 16.

[0121] In some exemplary modes, at decision block 304, the local agent 20 is configured to check whether the file is larger than a given size. The local agent 20 is configured to reject receiving a file larger than a given size limit from other medical device software update agents 20 (block 306).

[0122] In some exemplary modes, at decision block 308, the local agent 20 is configured to check whether the file reception rate exceeds a limit. The local agent 20 is configured to intercept the file provided by a given medical device (e.g., over a period of time) based on the given medical device 16 providing more than a given number of files within a given time period (block 310).

[0123] In some exemplary modes, at decision block 312, the local agent 20 is configured to check whether the local medical device 16 has exceeded a storage criterion (e.g., disk full or exceeding a limit, or queue full). The local agent 20 is configured to send a message to other medical device software update agents 20 to remove the local medical device 16 from the active routing data (e.g., remove from the routing table 48) in response to exceeding the storage criterion (block 314).

[0124] In some exemplary modes, the local agent 20 is configured to authenticate the received medical device software update based on the received digital signature (block 316) and delete files that fail the authentication process. The local agent 20 is configured to add details of the received files to the file delivery table 46 (block 318). The local agent 20 is configured to forward some or all of the files received from the cloud medical device software update agent 14 via the local agent 20 to other medical devices 16 in the network based on the corresponding destination information 56 of the files stored in the memory 38 ( Figure 5 ) and the corresponding routing information 66 of the evaluable medical devices in the routing table 48 ( Figure 5 ). One or more of the received files may be forwarded to the local medical device software 22 for installation. In an exemplary mode of performing the step of block 316, the step of block 320 is performed based on the authenticated files (e.g., medical device software updates).

[0125] The local agent 20 is configured to maintain a queue of the stored files for forwarding to the medical device 16 (block 322) using, for example, the file delivery table 46, and discard files from the medical device 16 according to the clearing policy of the queue, e.g., clear files older than a given value, or clear files in FIFO order when the queue size or total file size reaches a given value (block 324). The step of block 322 may include the local agent 20 generating a log to track the received files, the files forwarded to other medical devices 16, the files forwarded to the local medical device software 22 for installation, etc.

[0126] Now refer to Figure 13 , which is included in Figure 4400 of steps in a method for receiving and processing logs in a local medical device 16 of a cloud medical device. The local agent 20 is configured to receive logs of software installation and / or software updates from the local medical device software 22 running on the local medical device 16 (box 402). The local agent 20 is configured to digitally sign the received logs using the private key of the local medical device 16 so that it can be checked by the manufacturer of the local medical device 16 using the public key of the local medical device 16 (box 404). The local agent 20 is configured to optionally encrypt the logs using the public key of the manufacturer of the medical device 16. The local agent 20 is configured to receive logs from one or more other medical devices to forward to the cloud medical device software update agent 14 (box 406). The local agent 20 is configured to forward the received logs to the cloud medical device software update agent 14 via the interface 34 and one or more agents 20 installed in one or more corresponding other medical devices 16 (box 408).

[0127] Reference now Figure 14 , which is included in the received and processed by Figure 1 500 of steps in a method for receiving a log received by one of the cloud medical device software update agents 14 in the system 10. The cloud medical device software update agent 14 is configured to: receive a log from an agent 20 of a medical device 16 (block 502); authenticate (e.g., using a corresponding public key of the sending medical device 16) and optionally decrypt (e.g., using a corresponding private key of the manufacturer of the sending medical device 16) the log (block 504); identify a failure of a given software update agent 20 to relay a file from the cloud medical device software update agent 14 based on the received log (block 506); and in response to identifying the failure, perform an action for the given software update agent 20 (such as removing the agent's device from the routing table 48 for a given time period) (block 508).

[0128] As used herein, the term "about" or "approximately" for any numerical value or range indicates a suitable dimensional tolerance that allows a part or a collection of components to achieve its intended purpose as described herein. More specifically, "about" or "approximately" may refer to a range of ±20% of the value of the recited value, for example, "about 90%" may refer to a range of values ​​from 72% to 108%.

[0129] Examples

[0130] Example 1: A medical system includes a first medical device, and the first medical device includes: an interface configured to connect the first medical device to a network of multiple medical devices; and a processor configured to: run medical device software; run a first medical device software update agent configured to: receive identity information about the first medical device from the medical device software; send the identity information to a cloud medical device software update agent via the interface and at least one second medical device software update agent installed in at least one of the multiple medical devices; and receive, via the at least one second medical device software update agent installed in the at least one second medical device, a medical device software update and a digital signature of the medical device software update signed by a manufacturer of the first medical device; authenticate the received medical device software update based on the digital signature; and install the authenticated medical device software update.

[0131] Example 2: The system according to Example 1 further includes the multiple medical devices, where: the first medical device and the multiple medical devices are installed in a medical facility; a given medical device among the multiple medical devices is configured to establish an Internet connection with the cloud medical device software update agent; and the interface of the first medical device is configured to share data with the cloud medical device software update agent via the Internet using the Internet connection of the given medical device.

[0132] Example 3: The system according to Example 2, where the first medical device is a device that does not support the Internet.

[0133] Example 4: The system according to Example 2 or 3 further includes a cloud medical device software update agent of a first medical device manufacturer and another cloud medical device software update agent of a second medical device manufacturer, and the another cloud medical device software update agent is configured to connect to the cloud medical device software update agent of the first medical device manufacturer via another Internet connection.

[0134] Example 5: The system according to Example 4, where the cloud medical device software update agent of the first medical device manufacturer and the another cloud medical device software update agent of the second medical device manufacturer are configured to connect to medical devices of the first medical device manufacturer in the network of multiple medical devices via a first Internet connection and connect to medical devices of the second medical device manufacturer in the network of multiple medical devices via a second Internet connection, respectively.

[0135] Example 6: The system according to any one of Examples 2 to 5 further includes the cloud medical device software update agent, which is configured to: receive logs from the first medical device software update agent and the software update agents of the plurality of medical devices; identify, based on the received logs, a failure of a given software update agent among the software update agents to relay a file from the cloud medical device software update agent; and in response to identifying the failure, perform an action on the given software update agent.

[0136] Example 7: The system according to any one of Examples 1 to 6, wherein the first medical device includes a memory configured to store: a file delivery table including indications of one or more files received from the cloud medical device software update agent for delivery to one or more of the plurality of medical devices in the network, and corresponding destination information for the one or more files; and a routing table including identification information of evaluable medical devices among the medical devices in the network, and corresponding routing information for the evaluable medical devices.

[0137] Example 8: The system according to Example 7, wherein the first medical device software update agent is configured to forward the one or more files to one or more of the medical devices in the network based on the corresponding destination information of the one or more files received from the cloud medical device software update agent via the at least one second medical device software update agent and the corresponding routing information of the evaluable medical devices in the routing table.

[0138] Example 9: The system according to Example 7 or 8, wherein the memory is configured to store a direct neighbor table including a list of one or more direct neighbors of the first medical device and address information identifying the one or more direct neighbors in the network of medical devices.

[0139] Example 10: The system according to Example 9, wherein the first medical device software update agent is configured to: populate the routing table based on the list of the one or more direct neighbors; send the routing table to the one or more direct neighbors; receive one or more routing tables from the one or more direct neighbors; and augment the routing table based on data included in the received one or more routing tables, while removing the one or more duplicate destination medical devices based on considering the shortest route to one or more duplicate destination medical devices.

[0140] Example 11: The system according to any one of Examples 1 to 11, wherein the medical device software update is encrypted by the manufacturer of the first medical device using the public key of the first medical device, and the processor of the first medical device is configured to decrypt the medical device software update using the private key of the first medical device.

[0141] Example 12: The system according to any one of Examples 1 to 11, wherein the first medical device software update agent is configured to reject receiving files larger than a given size limit from other medical device software update agents.

[0142] Example 13: The system according to any one of Examples 1 to 12, wherein the first medical device software update agent is configured to receive an additional medical device software update and an additional corresponding digital signature from a given medical device among the plurality of medical devices, wherein: the processor is configured to check the additional digital signature and determine that the additional digital signature does not authenticate the additional medical device software update; and the first medical device software update agent is configured to intercept the file provided by the given medical device based on the failure of the given medical device to recognize the lack of authentication of the additional medical device software update.

[0143] Example 14: The system according to any one of Examples 1 to 12, wherein the first medical device software update agent is configured to: receive an additional medical device software update and an additional digital signature destined for a given medical device among the plurality of medical devices from the cloud medical device software update agent via the at least one second medical device software update agent; authenticate the received additional medical device software update based on the additional digital signature; and forward the additional medical device software update to the given medical device in response to authenticating the additional medical device software update based on the additional digital signature.

[0144] Example 15: The system according to any one of Examples 1 to 14, wherein the first medical device software update agent is configured to: maintain a queue of stored files for forwarding to one or more medical devices among the plurality of medical devices; and discard files from the first medical device according to the queue clearing policy.

[0145] Example 16: The system according to any one of Examples 1 to 15, wherein the first medical device software update agent is configured to send a message to the other medical device software update agents to remove the first medical device from the active routing data in response to exceeding a storage standard.

[0146] Example 17: The system according to any one of Examples 1 to 16, wherein the first medical device software update agent is configured to intercept files provided by a given medical device based on the given medical device in the plurality of medical devices providing more than a given number of files within a given time period.

[0147] Example 18: The system according to Examples 1 to 17, wherein the first medical device software update agent is configured to: receive logs of software installation and / or software updates from the medical device software running on the first medical device; and forward the received logs to the cloud medical device software update agent via the interface and the at least one second medical device software update agent.

[0148] Example 19: The system according to Example 18, wherein the first medical device software update agent is configured to digitally sign the logs using the private key of the first medical device for verification by the manufacturer of the first medical device using the public key of the first medical device.

[0149] Example 20: The system according to Example 19, further comprising a tamper-proof chip configured to store the private key of the first medical device.

[0150] Example 21: The system according to Example 18, wherein the first medical device software update agent is configured to encrypt the logs using the public key of the manufacturer of the first medical device.

[0151] Example 22: The system according to Example 1, wherein the first medical device software update agent is configured to: receive logs from at least one medical device among the plurality of medical devices; and forward the received logs to the cloud medical device software update agent via the at least one second medical device software update agent.

[0152] Example 23: A medical method, comprising: connecting a first medical device to a network of a plurality of medical devices; running medical device software; running a first medical device software update agent; receiving, by the first medical device software update agent, identity information about the first medical device from the medical device software; sending, by the first medical device software update agent, the identity information to a cloud medical device software update agent via at least one second medical device software update agent installed in at least one of the plurality of medical devices; receiving, by the first medical device software update agent via the at least one second medical device software update agent installed in the at least one second medical device, a medical device software update and a digital signature of the medical device software update signed by a manufacturer of the first medical device from the cloud medical device software update agent; authenticating the received medical device software update based on the digital signature; and installing the authenticated medical device software update.

[0153] Example 24: A software product, comprising a non-transitory computer-readable medium storing program instructions that, when read by a central processing unit (CPU), cause the CPU to: run medical device software; run a first medical device software update agent configured to: receive identity information about the first medical device from the medical device software; send the identity information to a cloud medical device software update agent via at least one second medical device software update agent installed in at least one second medical device; and receive, via the at least one second medical device software update agent installed in the at least one second medical device, a medical device software update and a digital signature of the medical device software update signed by a manufacturer of the first medical device from the cloud medical device software update agent; authenticate the received medical device software update based on the digital signature; and install the authenticated medical device software update.

[0154] For clarity, the various features of the present disclosure described in the context of separate exemplary modes may also be provided in combination in a single exemplary mode. Conversely, for brevity, the various features of the present disclosure described in the context of a single exemplary mode may also be provided separately or in any suitable sub-combination.

[0155] The above exemplary modes are cited by way of example, and the present disclosure is not limited to the content specifically shown and described above. Instead, the scope of the present disclosure includes combinations and sub-combinations of the various features described above, as well as their variations and modifications, which will occur to those skilled in the art upon reading the above description and which are not disclosed in the prior art.

Claims

1. A medical system (10), comprising a first medical device (16), wherein the first medical device comprises: an interface (34) configured to connect the first medical device (16) to a network of a plurality of medical devices (16); and a processor (36), the processor being configured to: running medical device software (22); Running a first medical device software update agent (20), wherein the first medical device software update agent is configured to: receiving, from the medical device software, identity information (42) regarding the first medical device (16); sending the identity information (42) to a cloud medical device software update agent (14) via the interface (34) and at least one second medical device software update agent (20) installed in at least one second medical device (16) among the plurality of medical devices (16); and receiving, from the cloud medical device software update agent (14) via the at least one second medical device software update agent (20) installed in the at least one second medical device (16), a medical device software update (26) and a digital signature of the medical device software update (26) signed by a manufacturer of the first medical device (16); authenticating the received medical device software update (26) based on the digital signature; and The authenticated medical device software update is installed (26).

2. The system of claim 1, further comprising the plurality of medical devices (16), wherein: The first medical device (16) and the plurality of medical devices (16) are installed in a medical facility (12); A given medical device among the plurality of medical devices (16) is configured to establish an internet connection (30) with the cloud medical device software update agent (14); and The interface (34) of the first medical device (16) is configured to share data (28) with the cloud medical device software update agent (14) via the Internet using the Internet connection (30) of the given medical device (16).

3. The system according to claim 2 further includes the cloud medical device software update agent (14) of the first medical device manufacturer and another cloud medical device software update agent (14) of the second medical device manufacturer, and the other cloud medical device software update agent is configured to connect to the cloud medical device software update agent (14) of the first medical device manufacturer via another Internet connection (30).

4. The system according to claim 3, wherein: The cloud medical device software update agent (14) of the first medical device manufacturer and the other cloud medical device software update agent (14) of the second medical device manufacturer are configured to be connected to a medical device (16-1) of the first medical device manufacturer in the network of multiple medical devices (16) via a first Internet connection (30), and to be connected to a medical device (16-2) of the second medical device manufacturer in the network of multiple medical devices (16) via a second Internet connection (30), respectively.

5. The system according to claim 2, further comprising the cloud medical device software update agent (14), wherein the cloud medical device software update agent is configured to: receiving logs (28) from the first medical device software update agent (20) and software update agents (20) of the plurality of medical devices (16); identifying a failure of a given one of the software update agents (20) to relay a file from the cloud medical device software update agent (14) based on the received log (28); and In response to identifying the failure, an action is performed for the given software update agent (20).

6. The system according to any one of claims 1 to 5, wherein: The first medical device (16) comprises a memory (38) configured to store: A file delivery table (46), the file delivery table comprising: an indication (54) of one or more files received from the cloud medical device software update agent (14) for delivery to one or more of the plurality of medical devices (16) in the network; and corresponding destination information (56) for the one or more files; and A routing table (48), the routing table comprising: identification information (64) of an assessable medical device in the medical devices (16) in the network; and The evaluable medical device's corresponding routing information (66).

7. The system according to claim 6, wherein: The first medical device software update agent (20) is configured to forward the one or more files to the one or more medical devices (16) in the network based on the corresponding destination information (56) of the one or more files received from the cloud medical device software update agent (14) via the at least one second medical device software update agent (20) and the corresponding routing information (66) of the evaluable medical device in the routing table (48).

8. The system according to claim 6, wherein: The memory (38) is configured to store a direct neighbor table (52), the direct neighbor table comprising: a list (74) of one or more direct neighbors of the first medical device (16), and Address information (76) identifying the one or more direct neighbors in the network of medical devices (16).

9. The system according to claim 8, wherein: The first medical device software update agent (20) is configured to: populating the routing table (48) based on the list (74) of the one or more direct neighbors; sending the routing table (48) to the one or more direct neighbors; as well as receiving one or more routing tables (48) from the one or more direct neighbors; as well as The routing table (48) is augmented based on the data included in the received one or more routing tables (48), while removing the one or more duplicate destination medical devices (16) based on considering the shortest route to the one or more duplicate destination medical devices (16).

10. The system according to any one of claims 1 to 5, wherein: The first medical device software update agent (20) is configured to receive an additional medical device software update (26) and an additional corresponding digital signature from a given medical device (16) of the plurality of medical devices (16), wherein: The processor (36) is configured to check the additional digital signature and determine that the additional digital signature does not authenticate the additional medical device software update (26); and The first medical device software update agent (20) is configured to intercept a file provided by the given medical device (16) based on the given medical device (16) failing to recognize that the additional medical device software update (26) lacks authentication.

11. The system according to any one of claims 1 to 5, wherein: The first medical device software update agent (20) is configured to: receiving, from the cloud medical device software update agent (14) via the at least one second medical device software update agent (20), an additional medical device software update (26) and an additional digital signature destined for a given medical device (16) of the plurality of medical devices (16); authenticating the received additional medical device software update (26) based on the additional digital signature; as well as In response to authenticating the additional medical device software update (26) based on the additional digital signature, the additional medical device software update (26) is forwarded to the given medical device (16).

12. The system according to any one of claims 1 to 5, wherein: The first medical device software update agent (20) is configured to send a message to other medical device software update agents (20) to remove the first medical device (16) from active routing data in response to exceeding a storage criterion.

13. The system according to any one of claims 1 to 5, wherein: The first medical device software update agent (20) is configured to: receiving a log (28) of software installations and / or software updates from the medical device software (22) running on the first medical device (16); and The received log (28) is forwarded to the cloud medical device software update agent (14) via the interface (34) and the at least one second medical device software update agent (20).

14. The system of claim 1, wherein: The first medical device software update agent (20) is configured to: receiving a log (28) from at least one medical device of the plurality of medical devices (16); and The received log (28) is forwarded to the cloud medical device software update agent (14) via the at least one second medical device software update agent (20).

15. A medical method comprising: connecting a first medical device (16) to a network of a plurality of medical devices (16); running medical device software (22); Running a first medical device software update agent (20); Receiving (202) identity information (42) about the first medical device (16) from the medical device software (22) by the first medical device software update agent (20); The first medical device software update agent (20) sends (204) the identity information (42) to a cloud medical device software update agent (14) via at least one second medical device software update agent (20) installed in at least one second medical device (16) among the plurality of medical devices (16); receiving (208) by the first medical device software update agent (20) via the at least one second medical device software update agent (20) installed in the at least one second medical device (16), from the cloud medical device software update agent (14), a medical device software update (26) and a digital signature of the medical device software update (26) signed by a manufacturer of the first medical device (16); authenticating (210) the received medical device software update (26) based on the digital signature; and The authenticated medical device software update (26) is installed (214).

Images