Distributed secure distribution of software update to medical device

Abstract

To provide a medical system that distributes software update of a medical device.SOLUTION: A system 10 includes a cloud medical device software update agent 14 and a medical device 16. The medical device is installed in a medical treatment facility 12. The medical treatment facility includes a firewall 18 that provides protection of the medical device from an external traffic. Each medical device includes a medical device software update agent 20 and medical device software 22. The medical device in the medical treatment facility forms a network and is connected via any preferable data connection 24. The medical device 16-1 establishes one or two or more corresponding internet connections 30 with the cloud medical device software update agent. The cloud medical device software update agent transmits software update 26 to the medical device and receives a log from the medical device.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims priority to U.S. Provisional Patent Application No. 63 / 612,525, filed on December 20, 2023, by Ravuna et al., titled "Decentralized secure distribution of software updates to medical devices", the disclosure of which is incorporated herein by reference.

[0002] (Field of the Invention) The present disclosure relates to medical systems, and more particularly, although not exclusively, to the distribution of software updates for medical devices.

Background Art

[0003] Software updates are important for digital security and cyber - security, providing other benefits including fixing security holes, correcting computer bugs, and adding new features to devices. Hackers can exploit software vulnerabilities, for example, by writing code that targets the vulnerabilities.

[0004] Updating software and operating systems helps keep hackers out, protects data, and ensures that software operates according to the latest operating methods, which is particularly essential in medical devices that handle sensitive data and run life - critical or other applications.

Brief Description of the Drawings

[0005] The present disclosure will be understood from the following detailed description in conjunction with the accompanying drawings.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

DETAILED DESCRIPTION OF THE INVENTION

[0006] Summary As described above, in order to maintain safety, security, and effectiveness throughout the product life cycle, it is essential to update device software as needed. This is particularly important for medical devices. According to "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" issued by the US Food and Drug Administration (FDA) on September 27, 2023, timely updatability and patch applicability are one of the security objectives evaluated by the FDA when inspecting medical devices.

[0007] Many medical devices within medical facilities such as hospitals are not directly connected to the Internet, for example, due to security reasons and / or lack of device capabilities. Therefore, such devices do not receive relevant cybersecurity and other updates in a timely manner, even if available. This is particularly crucial for these updates as cybersecurity updates need to be distributed quickly. Delays in distributing cybersecurity updates increase the risk of zero-day attacks.

[0008] Accordingly, an exemplary mode of the present disclosure addresses some of these drawbacks by providing a system in which a medical device installed within 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. While not all medical devices are connected to the Internet, one or more of the medical devices may be connected to the Internet to receive software updates from a cloud software update agent on behalf of medical devices that are not directly connected to the Internet. Medical devices that are not directly connected to the Internet are still (directly or indirectly) connected to medical devices that are connected to the Internet via a suitable communication link, such as, for example, a USB connection and / or an Ethernet connection. The received software update can then be distributed via a network of agents installed within the medical devices within the medical facility. In this way, the software update can be transferred to all connected medical devices within the medical facility to ensure that each device has updated its medical software. The cloud software agent can provide software updates to different manufacturers of medical devices installed within the medical facility. In some exemplary embodiments, the cloud software agent may include an agent for each manufacturer of medical devices installed within the medical facility. For example, a cloud software agent for manufacturer A may be connected to medical devices of manufacturer A within the medical facility, and a cloud software agent for manufacturer B may be connected to medical devices of manufacturer B within the medical facility.

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

[0010] The agent installed within the medical device executes a discovery method to discover the medical device installed within the medical facility, the cloud agent, and the topology of the connection between the medical device and the cloud agent, as described in the disclosed exemplary embodiments. The discovery method results in a routing table installed within each of the medical device and the cloud agent, enables files such as software updates to be transferred from the cloud agent to the relevant medical device, and enables software update logs and other log files to be transferred from the medical device to the cloud agent. The discovery method may be applied to a basic topology or a more complex mesh topology, including loops, as explained in the disclosed exemplary embodiments.

[0011] The agent operating within the medical device provides the received software update installed within that medical device and may transfer other received software updates to other medical devices according to the destination address of the corresponding received software update. The agent operating within the medical device may receive logs from that medical device or other medical devices for transfer to the cloud agent via one or more medical devices installed within the medical facility. In some cases, when the medical device is directly connected to the Internet, that medical device may transfer logs to the cloud agent via the Internet connection.

[0012] Each agent may maintain and store a file distribution table (providing instructions for files received for distribution such as file names and corresponding destination information such as model number and serial number), a routing table (providing identification information for evaluable medical devices such as model number and serial number, corresponding routing information such as the number of hops to the medical device, and which neighbor to go through), and a direct neighbor table (providing a list of direct neighbor devices such as model number and serial number and corresponding address information such as the IP address of the direct neighbor).

[0013] The system may include various security features that will be described in more detail below.

[0014] In some exemplary embodiments, 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. The signature can be verified by the medical device on which the software update is installed, for example, using the corresponding manufacturer's public key or certificate. The file can optionally be encrypted, for example, using the public key of the corresponding medical device, for decryption by the corresponding medical device's private key.

[0015] In some exemplary embodiments, one or more (e.g., all) agents not installed on the target device of the software update can also verify 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 is intended to verify the signature, for example, the adjacent device may be assumed to have not done a good job because it may be infected or compromised, or there may be a hacker mimicking the adjacent device. In this case, the medical device can automatically block the adjacent device, for example, for a predetermined period of time.

[0016] In some exemplary modes, if an infected medical device refuses to relay a file, the cloud agent can identify this behavior based on analyzing the received log file to determine that the target medical device does not recognize the installation of the software update and / or which medical device is not relaying the file. The operator can then block the medical device that does not relay the file (e.g., remove it from the routing table) so that, if another available path exists, the file arrives at the destination automatically without going through the blocked medical device.

[0017] The logs can be signed (e.g., with the private key of the medical device that generates the logs) and authenticated in the cloud using the corresponding public key. For example, a tamper-resistant chip such as a trusted platform model (TMP) according to the ISO / IEC 11889 standard can be used to store the private key of the medical device. The logs can optionally be encrypted using the manufacturing public key for decryption by the cloud agent.

[0018] In some exemplary embodiments, the agent can limit the size of the files it is permitted to receive in order to prevent an attacker from sending large files to deplete disk space, as signatures are generally verified at the end of the transmission. In some exemplary embodiments, files awaiting delivery within the medical device can be purged from the queue of files to be delivered if they have been in the queue for longer than a given time limit (e.g., number of days). In some exemplary embodiments, files awaiting delivery within the medical device can be purged from the queue, for example, on a first-in-first-out (FIFO) basis, when the maximum queue size is reached.

[0019] In some exemplary embodiments, if the medical device runs out of disk space, the medical device can actively send a message to its neighbors asking to be removed from the routes in the routing table. In some exemplary embodiments, if a medical device is sending too many files in a given period, this medical device can be marked as suspicious and blocked for a certain amount of time.

[0020] Description of the System Referring now to FIG. 1, FIG. 1 is a block diagram of a computer system 10 within a medical facility 12 constructed and operative in accordance with an exemplary aspect of the present disclosure. The system 10 includes a cloud medical device software update agent 14 and medical devices 16. The medical devices 16 are installed within the medical facility 12. The medical facility 12 includes a firewall 18 that provides protection of the medical devices 16 from external traffic. Each medical device 16 includes a medical device software update agent 20 and medical device software 22. The medical devices 16 within the medical facility 12 form a network and are connected via any suitable data connection 24, such as a USB connection and / or an 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 agent 14. The cloud medical device software update agent 14 is configured to send software updates 26 to the medical devices 16 and receive logs 28 from the medical devices 16, which will be described in more detail below. The cloud medical device software update agent 14 may include a server of a medical device manufacturer within the cloud. For example, the cloud medical device software update agent 14 may be implemented using Microsoft's Azure™ IoT System or PTC's ThingWorx™ Server.

[0021] Here, referring to FIG. 2, FIG. 2 is a block diagram of another computer system 50 within the medical facility 12 constructed and operating in accordance with another exemplary aspect of the present disclosure. The computer system 50 is substantially the same as the system 10, except for the following differences. The computer system 50 includes two cloud medical device software update agents 14 for two corresponding manufacturers. In the example of FIG. 2, 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.

[0022] Here, referring to FIG. 3, FIG. 3 is a block diagram of another computer system 60 within the medical facility 12 constructed and operating in accordance with yet another exemplary aspect of the present disclosure. The system 60 is substantially the same as the computer system 50, except for the following differences. Both of the cloud medical device software update agents 14 are connected to at least one device 16 within the medical facility 12 via the Internet connection 30. In the example of FIG. 3, 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. via the Internet connection 30 within the medical facility 12, and the cloud medical device software update agent 14 of ACME, Inc. is configured to be connected to a medical device 16-2 of ACME, Inc. via another one of the Internet connections 30.

[0023] Here, referring to FIG. 4, FIG. 4 is a block diagram of one of the medical devices 16 (e.g., medical device 16-3) within the system 10 of FIG. 1. The medical device 16 includes an interface 34, a processor 36, a memory 38, and optionally a tamper-resistant chip 40.

[0024] Interface 34 can be any suitable interface, such as an Ethernet-compatible interface, a USB-compatible interface, and / or an Internet-compatible interface. As described above, one or more medical devices 16 are directly connected to the Internet, while other medical devices 16 are not. One or more of the medical devices 16 can be non-Internet-compatible devices, and non-Internet-compatible devices cannot connect to the Internet alone or even process Internet Protocol (IP) packets, but can share data on the Internet through 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.

[0025] Processor 36 is configured to execute agent 20 and medical device software 22. Agent 20 is configured to receive software update 26 from cloud medical device software update agent 14 via interface 34 and optionally one or more other medical devices 16. The received software update 26 may include one or more software updates 26 for transfer to other medical devices 16 via interface 34. Agent 20 may also provide software update 26 to update medical device software 22. Medical device software 22 may provide log 28 to agent 20. Agent 20 may also receive log 28 from agent 20 of other medical devices 16 via interface 34. Agent 20 transfers the received log via interface 34 and optionally via one or more medical devices 16 to cloud medical device software update agent 14. Medical device software 22 may provide identification information 42 such as model and serial number to agent 20 for transfer to cloud medical device software update agent 14, as described in more detail with reference to FIG. 11. Medical device software 22 may provide direct neighbor identification 44 to agent 20, as described in more detail below with reference to FIG. 5.

[0026] Agent 20 is configured to maintain tables including file distribution table 46, routing table 48, and direct neighbor table 52. Memory 38 is configured for the stored tables 46, 48, 52, as described in more detail below with reference to FIG. 5.

[0027] Tamper-resistant chip 40 is configured to store the private key of 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 FIGS. 11 and 13.

[0028] In practice, some or all of the functions of the processor 36 can be implemented by combining them into a single physical component, or alternatively, using multiple physical components. These physical components can include hardwired devices or programmable devices, or a combination of the two. In some exemplary modes, at least some of the functions of the processor 36 may be executed by a programmable processor under the control of suitable software. This software can be downloaded to the device in electronic form via a network, for example. Alternatively or additionally, this software can be stored in a tangible non-transitory computer-readable storage medium such as optical memory, magnetic memory, or electronic memory.

[0029] Referring now to FIG. 5, FIG. 5 is a block diagram of the memory 38 and the stored tables within the device 16 of FIG. 4.

[0030] The file distribution table 46 includes one or more file instructions 54 received from the cloud medical device software update agent 14 for distribution to one or two or more of the plurality of medical devices 16 within the network, and the corresponding destination information 56 for the files. The instruction 54 can include a file name 58, and the destination information 56 can include the model and serial number 62 of each corresponding entry within the file distribution table 46.

[0031] The routing table 48 includes the identification information 64 of the evaluable medical devices among the medical devices 16 within the network, and the corresponding routing information 66 of the evaluable medical devices 16. The identification information 64 can include the model and serial number 68, and the routing information 66 can include the number of hops 70 and which neighbor 72 to pass through for each entry within the table. The routing table 48 will be described in more detail with reference to FIGS. 6-10.

[0032] 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 for identifying one or more direct neighbors within the network of the medical device 16. The list 74 may include a model and serial number 78 for each entry within the direct neighbor table 52. The address information 76 may include an IP address 80 for each corresponding entry within the table. A direct neighbor is one of the medical devices 16 that is directly connected to the medical device 16 in which the direct neighbor table 52 is stored, without an intervening medical device 16. The direct neighbor table 52 may be populated based on direct neighbor identification 44 (FIG. 4) received from the medical device software 22.

[0033] Now referring to FIGS. 6 - 9, FIGS. 6 - 9 are diagrams of a routing table 48 showing the generation of the routing table 48 used in the system 10 of FIG. 1.

[0034] FIGS. 6 - 9 show devices 16 labeled for convenience as devices A - E, and the cloud agent 14. The cloud medical device software update agent 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.

[0035] FIG. 6 shows that each agent 14, 20 adds its own device to its own routing table 48 listing the destination as the name of its own device, sets "via" locally, and sets the hop count to 0.

[0036] Figure 7 shows that each agent 14, 20 adds its direct neighbors to its own routing table 48 based on the direct neighbor table 52 of each agent 14. 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 is set to 1.

[0037] Figure 8 shows the result of each agent 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 agents 14, 20 to update its own routing table 48, as will be described in more detail here.

[0038] Each entry in the received routing table is updated such that each hop count is incremented by 1 only, and "via" is set to identify the entity that sent the routing table. For example, if the routing table 48 is received from device A, "via" is set to device A. Additionally, duplicate entries are removed and the entry with the fewest hop counts is left, as illustrated in the following example.

[0039] For example, when device C receives the routing table 48 from device D, device C has the following entries (as shown in Figure 7): Receive D via local at hop count 0, Receive C directly at hop count 1, Receive E directly at hop count 1.

[0040] The above entries are updated by the agent 20 of device C to: Update D to D via D at hop count 1, Update C to C via D at hop count 2, Update E to E via D at hop count 2.

[0041] Also, device C receives the routing table 48 from device B and has the following entries (as shown in Figure 7): Receive B via local route with hop count 0, Receive the cloud via direct route with hop count 1, Receive A via direct route with hop count 1, Receive C via direct route with hop count 1.

[0042] The above entries are updated by the agent 20 of device C Updated to B via B with hop count 1, Updated to the cloud via B with hop count 2, Updated to A via B with hop count 2, Updated to C via B with hop count 2.

[0043] Also, device C receives the routing table 48 from device E and has the following entries (as shown in Figure 7): Receive E via local route with hop count 0, Receive D via direct route with hop count 1, Receive C via direct route with hop count 1.

[0044] The above entries are updated by the agent 20 of device C Updated to E via E with hop count 1, Updated to D via E with hop count 2, Updated to C via E with hop count 2.

[0045] The original entries in the routing table 48 of device C in Figure 7 are as follows: 1. C via local route with hop count 0. 2. B via direct route with hop count 1. 3. D via direct route with hop count 1. 4. E via direct route with hop count 1.

[0046] The following entries are candidates for addition to the routing table 48 of device C based on the above: 5. To D via D with a hop count of 1. 6. To C via D with a hop count of 2. 7. To E via D with a hop count of 2. 8. To B via B with a hop count of 1. 9. To the cloud via B with a hop count of 2. 10. To A via B with a hop count of 2. 11. To C via B with a hop count of 2. 12. To E via E with a hop count of 1. 13. To D via E with a hop count of 2. 14. To C via E with a hop count of 2.

[0047] The above 14 items can be analyzed for duplicates as follows.

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

[0049] Items 2 and 8 provide routing information to device B. The entries are identical, so either one can be removed.

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

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

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

[0053] Item 9 provides routing information to the cloud and is thus retained.

[0054] When the above item is deleted, the following items remain in the routing table 48 of device C: 1. It is C via local with hop count 0. 2. It is B directly with hop count 1. 3. It is D directly with hop count 1. 4. It is E directly with hop count 1. 9. It is the cloud via B with hop count 2. 10. It is A via B with hop count 2.

[0055] The above also corresponds to the entries shown in the routing table 48 of device C in FIG. 8.

[0056] The updated routing table 48 is shared again with the direct neighbors and processed as described above to update the "via" and "hop" values as appropriate, remove duplicates based on retaining the entry with the shortest hop, and generate the routing table 48 shown in FIG. 9.

[0057] In some implementations, the routing table 48 may need to be shared multiple times and processed as described above until it reaches a steady state.

[0058] Referring now to FIG. 10, FIG. 10 is a flowchart 100 including steps in a method for generating a routing table 48 for use in the system 10 of FIG. 1. Agent 20 is configured to populate 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). Agent 20 is configured to send routing table 48 (i.e., its local routing table 48) to one or more direct neighbors (block 104) and to receive routing table 48 from the direct neighbors (block 106). Agent 20 is configured to expand routing table 48 (i.e., its local routing table 48) based on data included in the received routing table (e.g., by updating the "via" value to the ID of the device that sent routing table 48 and by incrementing the "hop" value by 1 for each entry in the received routing table 48), while removing entries for one or more duplicate destination medical devices based on consideration of the shortest path (i.e., the lowest number of hops) by retaining the entry with the shortest path (block 108). The steps of blocks 104-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 reach a steady state (i.e., stop changing).

[0059] Referring now to FIG. 11, FIG. 11 is a flowchart 200 including steps in a method for providing a software update to one of the devices 16 of FIG. 4. The terms local agent 20 and local medical device software 22 are used to refer to agent 20 and medical device software 22 that are executed on the same local medical device 16.

[0060] The local agent 20 that executes within the local medical device 16 is configured to receive identification information 42 regarding the local medical device 16 from the local medical device software 22 (block 202). The local agent 20 is configured to transmit the identification information 42 to the cloud medical device software update agent 14 via the local interface 34 and one or more other corresponding agents 20 installed within one or two or more other corresponding medical devices 16 (block 204). The cloud medical device software update agent 14 receives the identification information 42, signs the software update 26 with the private key of the manufacturer of the local medical device 16, and optionally encrypts the software update 26 with the public key of the local medical device 16, and is configured to transmit the software update 26 and its signature to the local medical device 16 via other agents 20 (block 206). The local agent 20 is configured to receive from the cloud medical device software update agent 14, via other agents 20 installed within other medical devices 16, 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 (block 208).

[0061] The processor 36 or 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 by the manufacturer of the local medical device 16 using the public key of the local medical device 16, the processor 36 of the medical device 16 is configured to decrypt the medical device software update 26 using the private key of the local medical device 16 (e.g., stored in the tamper-resistant chip 40 (FIG. 4)) (block 210).

[0062] In decision block 212, the processor 36 or agent 20 of the local medical device 16 is configured to check 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).

[0063] When the local agent 20 sends the software update 26 to the medical device software 22, the medical device software 22 may notify the user of the local medical device 16, so that the user can select an appropriate time to install the update. Alternatively, the update may be automatically installed when the device is idle. In this case, the local medical device 16 may provide an option to cancel the update. If there is an emergency and the hospital staff immediately need the device, the hospital staff can cancel the update during installation and use the medical device. Alternatively, the update may be automatically installed outside of working hours. In this case as well, the local medical device 16 may provide an option to cancel the update.

[0064] 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 it was intended that another medical device 16 first check the digital signature, the local agent 20 may be configured to block the file provided by the other medical device 16 based on the other medical device's failure to identify the lack of authentication of the medical device software update 26.

[0065] Now referring to FIG. 12, FIG. 12 is a flowchart 300 including steps in a method of receiving and processing a file in the local medical device 16 of FIG. 4.

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

[0067] In some exemplary aspects, 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 the receipt of a file larger than a given size limit from another medical device software update agent 20 (block 306).

[0068] In some exemplary aspects, 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 block files provided by a given medical device 16 (e.g., over a period of time) based on the given medical device providing more files than a given number within a given period (block 310).

[0069] In some exemplary aspects, at decision block 312, the local agent 20 is configured to check whether the local medical device 16 has exceeded a memory criterion (e.g., disk full or limit exceeded or queue full). The local agent 20 is configured to send a message to another medical device software update agent 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 memory criterion (block 314).

[0070] In some exemplary embodiments, the local agent 20 is configured to authenticate the received medical device software update (block 316) based on the received digital signature and delete files that failed the authentication process. The local agent 20 is configured to add details of the received files to the file distribution table 46 (block 318). The local agent 20 is configured to transfer 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 file (FIG. 5) and the corresponding routing information 66 of the evaluable medical devices in the routing table 48 stored in the memory 38 (FIG. 5) (block 320). One or more of the received files may be transferred to the local medical device software 22 for installation. In an exemplary embodiment in which the step of block 316 is performed, the step of block 320 is performed based on the authenticated file (e.g., medical device software update).

[0071] The local agent 20 is configured to maintain, for example, a queue of stored files for transfer to the medical device 16 using the file distribution table 46 (block 322) and discard files from the medical device 16 according to a queue purge policy, e.g., purge files older than a given value or purge files on a FIFO basis 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 for tracking received files, files transferred to other medical devices 16, files transferred to the local medical device software 22 for installation, and the like.

[0072] Referring now to FIG. 13, FIG. 13 is a flowchart 400 including steps in a method for receiving and processing logs in the local medical device 16 of FIG. 4. The local agent 20 is configured to receive logs of software installation and / or software updates from the local medical device software 22 executed on the local medical device 16 (block 402). The local agent 20 is configured to digitally sign the received logs using the private key of the local medical device 16 for verification by the manufacturer of the local medical device 16 using the public key of the local medical device 16 (block 404). The local agent 20 is optionally configured to encrypt the logs with 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 for transfer to the cloud medical device software update agent 14 (block 406). The local agent 20 is configured to transfer 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 (block 408).

[0073] Referring now to FIG. 14, FIG. 14 is a flowchart 500 including steps in a method of receiving and processing logs received by one of the cloud medical device software update agents 14 within the system 10 of FIG. 1. The cloud medical device software update agent 14 receives logs from the agent 20 of the medical device 16 (block 502), authenticates the logs (e.g., using the corresponding public key of the sending medical device 16) and optionally decrypts the logs (e.g., using the corresponding private key of the manufacturer of the sending medical device 16) (block 504), based on the received logs, identifies that a given software update agent 20 has failed to relay a file from the cloud medical device software update agent 14 (block 506), and in response to identifying the failure, performs an action regarding the given software update agent 20 (such as removing the agent's device from the routing table 48 over a given period) (block 508), and is configured to do so.

[0074] As used herein, the term "about" or "substantially" with respect to any numerical value or numerical range indicates a preferred dimensional tolerance that allows a part or a set of components to function for its intended purpose as described herein. More specifically, "about" or "substantially" can refer to a range of values of ±20% of the recited value, for example, "about 90%" can refer to a range of values from 72% to 108%.

Example

[0075] Example 1: A medical system comprising a first medical device, the first medical device having an interface configured to connect the first medical device to a network of a plurality of medical devices, a processor configured to execute medical device software and to execute a first medical device software update agent, the first medical device software update agent receiving identification information regarding the first medical device from the medical device software and transmitting the identification 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 receiving, from the cloud medical device software update agent via at least one second medical device software update agent installed in 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, the processor being further configured to authenticate the received medical device software update based on the digital signature and to install the authenticated medical device software update.

[0076] Example 2: The system according to Example 1, further comprising a plurality of medical devices, the first medical device and the plurality of medical devices being installed within a medical facility, a given one of the plurality of medical devices being configured to establish an Internet connection with a cloud medical device software update agent, and the interface of the first medical device being configured to share data with the cloud medical device software update agent via the Internet using the Internet connection of the given medical device.

[0077] Example 3: The system according to Example 2, wherein the first medical device is a non-Internet-enabled device.

[0078] Example 4: The system according to Example 2 or 3, further comprising 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 configured to connect to the cloud medical device software update agent of the first medical device manufacturer via a separate Internet connection.

[0079] Example 5: The system according to Example 4, wherein the cloud medical device software update agent of the first medical device manufacturer and the other cloud medical device software update agent of the second medical device manufacturer are each connected to a medical device of the first medical device manufacturer within a network of a plurality of medical devices via a first Internet connection and are connected to a medical device of the second medical device manufacturer within a network of a plurality of medical devices via a second Internet connection.

[0080] Example 6: The system according to any one of Examples 2 to 5, further comprising a cloud medical device software update agent, wherein the cloud medical device software update agent is configured to receive logs from a first medical device software update agent and software update agents of a plurality of medical devices, identify that a given one of the software update agents has failed to relay a file from the cloud medical device software update agent based on the received logs, and execute an action regarding the given software update agent in response to identifying the failure.

[0081] Example 7: A system according to any one of Examples 1 to 6, comprising a memory configured to store a file distribution table including instructions of one or more files received from a cloud medical device software update agent for distribution to one or two or more of a plurality of medical devices in a network, and corresponding destination information of 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 of the evaluable medical devices.

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

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

[0084] Example 10: The system according to Example 9, wherein the first medical device software update agent is configured to populate a routing table based on a list of one or more direct neighbors, transmit the routing table to one or more direct neighbors, receive one or more routing tables from one or more direct neighbors, expand the routing table based on data included in the received one or more routing tables, while removing one or more duplicate destination medical devices based on consideration of the shortest path to one or more duplicate destination medical devices.

[0085] 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.

[0086] 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 receipt of a file larger than a given size limit from another medical device software update agent.

[0087] 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 additional medical device software updates and corresponding additional digital signatures from a given medical device among a plurality of medical devices, the processor is configured to verify 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 block a file provided by the given medical device based on the given medical device failing to identify the lack of authentication of the additional medical device software update.

[0088] Example 14: A first medical device software update agent receives additional medical device software updates and additional digital signatures addressed to a given medical device among a plurality of medical devices via at least one second medical device software update agent from a cloud medical device software update agent; authenticates the received additional medical device software updates based on the additional digital signatures; and in response to authenticating the additional medical device software updates based on the additional digital signatures, transfers the additional medical device software updates to the given medical device. The system according to any one of Examples 1 to 12, which is configured to perform the above operations.

[0089] Example 15: A first medical device software update agent maintains a queue of stored files for transfer to one or more of a plurality of medical devices; and discards files from the first medical device according to a purge policy of the queue. The system according to any one of Examples 1 to 14, which is configured to perform the above operations.

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

[0091] Example 17: A first medical device software update agent is configured to block files provided by a given medical device based on the given medical device providing more files than a given number within a given period among a plurality of medical devices. The system according to any one of Examples 1 to 16, which is configured to perform the above operations.

[0092] Example 18: The system according to any one of Examples 1 to 17, wherein a first medical device software update agent is configured to receive a log of software installation and / or software update from medical device software executed on a first medical device, and transfer the received log to a cloud medical device software update agent via an interface and at least one second medical device software update agent.

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

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

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

[0096] Example 22: The system according to Example 1, wherein a first medical device software update agent is configured to receive a log from at least one of a plurality of medical devices, and transfer the received log to a cloud medical device software update agent via at least one second medical device software update agent.

[0097] Example 23: A medical method, comprising connecting a first medical device to a network of a plurality of medical devices, executing medical device software, executing a first medical device software update agent, receiving, by the first medical device software update agent, identification information regarding the first medical device from the medical device software, transmitting, by the first medical device software update agent, the identification 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 among the plurality of medical devices, receiving, by the first medical device software update agent, from the cloud medical device software update agent via at least one second medical device software update agent installed in 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, authenticating the received medical device software update based on the digital signature, and installing the authenticated medical device software update.

[0098] Example 24: A software product including a non-transitory computer-readable medium storing program instructions, which, when read by a central processing unit (CPU), cause the CPU to execute medical device software and execute a first medical device software update agent, receive identification information regarding a first medical device from the medical device software, transmit the identification 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 from the cloud medical device software update agent, via at least one second medical device software update agent installed in at least one second medical device, a medical device software update and a digital signature of the medical device software update signed by the 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.

[0099] Although various features of the present disclosure have been described in the context of separate exemplary aspects for clarity, these may be provided in combination in a single exemplary aspect. Conversely, the various features of the present disclosure described in the context of a single exemplary aspect for brevity may be provided separately or in any suitable partial combination.

[0100] The above-described exemplary aspects are given by way of example, and the present disclosure is not limited to those specifically shown and described above. Rather, the scope of the present disclosure includes both combinations and partial combinations of the various features described in the above specification, as well as those variations and modifications thereof that would occur to those skilled in the art upon reading the above description and are not disclosed in the prior art.

[0101] 〔Embodiments〕 (1) A medical system comprising a first medical device, wherein the first medical device is configured to connect the first medical device to a network of a plurality of medical devices, an interface, and a processor, the processor being configured to execute medical device software, execute a first medical device software update agent, the first medical device software update agent being configured to receive identification information regarding the first medical device from the medical device software, send the identification 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 among the plurality of medical devices, receive, from the cloud 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, authenticate the received medical device software update based on the digital signature, and install the authenticated medical device software update, the processor being configured to perform the above operations, a medical system. (2) Further comprising the plurality of medical devices, wherein the first medical device and the plurality of medical devices are installed in a medical facility, wherein a given one of the plurality of medical devices is configured to establish an Internet connection with the cloud medical device software update agent, The system according to embodiment 1, wherein 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. (3) The system according to embodiment 2, wherein the first medical device is a non-Internet-compatible device. (4) The system according to embodiment 2, further comprising 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 configured to connect to the cloud medical device software update agent of the first medical device manufacturer via another Internet connection. (5) The system according to embodiment 4, wherein 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 each connected to a medical device of the first medical device manufacturer within the network of the plurality of medical devices via a first Internet connection and connected to a medical device of the second medical device manufacturer within the network of the plurality of medical devices via a second Internet connection.

[0102] (6) Further comprising the cloud medical device software update agent, wherein the cloud medical device software update agent: receives logs from the first medical device software update agent and the software update agents of the plurality of medical devices; identifies that a given one of the software update agents has failed to relay a file from the cloud medical device software update agent based on the received logs; The system according to embodiment 2, configured to perform, in response to identifying the failure, an action regarding the given software update agent. (7) The first medical device A file distribution table, Instructions for one or more files received from the cloud medical device software update agent for distribution to one or more of the plurality of medical devices in the network, And corresponding destination information for the one or more files, a file distribution table. A routing table, Identification information of evaluable medical devices among the medical devices in the network, And corresponding routing information for the evaluable medical devices, a routing table, a system according to embodiment 1 including a memory configured to store. (8) The first medical device software update agent transfers 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 to the one or more medical devices in the network based on the corresponding destination information of the one or more files and the corresponding routing information of the evaluable medical devices in the routing table. The system according to embodiment 7, configured as such. (9) The memory A list of one or more direct neighbors of the first medical device, And address information for identifying the one or more direct neighbors in the network of the medical device, a system according to embodiment 7 including a memory configured to store a direct neighbor table including the same. (10) The first medical device software update agent Populating the routing table based on the list of the one or more direct neighbors; Transmitting the routing table to the one or more direct neighbors; Receiving one or more routing tables from the one or more direct neighbors; While expanding the routing table based on data included in the received one or more routing tables, removing the one or more duplicate destination medical devices based on consideration of the shortest path to the one or more duplicate destination medical devices, the system according to embodiment 9, configured to perform.

[0103] (11) 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, the system according to embodiment 1. (12) The first medical device software update agent is configured to reject receipt of a file larger than a given size limit from other medical device software update agents, the system according to embodiment 1. (13) The first medical device software update agent is configured to receive additional medical device software updates and additional corresponding digital signatures from a given medical device among the plurality of medical devices, The processor is configured to verify the additional digital signature and determine that the additional digital signature does not authenticate the additional medical device software update, The system according to Embodiment 1, wherein the first medical device software update agent is configured to block a file provided by the given medical device based on a failure of the given medical device to identify a lack of authentication of the additional medical device software update. (14) The first medical device software update agent receives an additional medical device software update and an additional digital signature addressed to 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; authenticates the received additional medical device software update based on the additional digital signature; and transfers 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, the system according to Embodiment 1. (15) The first medical device software update agent maintains a queue of stored files for transfer to one or more of the plurality of medical devices; and discards files from the first medical device according to a purge policy of the queue, the system according to Embodiment 1.

[0104] (16) 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 active routing data in response to exceeding a storage criterion, the system according to Embodiment 1. (17) The system according to embodiment 1, wherein the first medical device software update agent is configured to block files provided by a given medical device among the plurality of medical devices based on the given medical device providing more files than a given number within a given period. (18) The first medical device software update agent is configured to receive a log of software installation and / or software update from the medical device software executed on the first medical device, and transfer the received log to the cloud medical device software update agent via the interface and the at least one second medical device software update agent. The system according to embodiment 1. (19) The system according to embodiment 18, wherein the first medical device software update agent is configured to digitally sign the log 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. (20) The system according to embodiment 19, further comprising a tamper-resistant chip configured to store the private key of the first medical device.

[0105] (21) The system according to embodiment 18, wherein the first medical device software update agent is configured to encrypt the log using the public key of the manufacturer of the first medical device. (22) The first medical device software update agent is configured to receive a log from at least one of the plurality of medical devices, and transfer the received log to the cloud medical device software update agent via the at least one second medical device software update agent. The system according to embodiment 1. (23) A medical method, comprising: connecting a first medical device to a network of a plurality of medical devices; executing medical device software; executing a first medical device software update agent; receiving, by the first medical device software update agent, identification information regarding the first medical device from the medical device software; transmitting, by the first medical device software update agent, the identification 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 among the plurality of medical devices; receiving, by the first medical device software update agent, from the cloud 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; authenticating the received medical device software update based on the digital signature; installing the authenticated medical device software update. (24) A software product including a non-transitory computer-readable medium storing program instructions that, when read by a central processing unit (CPU), cause the CPU to execute medical device software; execute a first medical device software update agent, wherein the first medical device software update agent receives identification information regarding the first medical device from the medical device software, Transmit the identification information to the cloud medical device software update agent via at least one second medical device software update agent installed in at least one second medical device. Be configured to receive, from the cloud 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 the manufacturer of the first medical device. Authenticate the received medical device software update based on the digital signature. A software product that causes the authenticated medical device software update to be installed.

Claims

1. A medical system (10) comprising a first medical device (16), 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), executing medical device software (22); executing a first medical device software update agent (20), the first medical device software update agent (20) comprising: receiving identification information (42) regarding the first medical device (16) from the medical device software; transmitting said identification information (42) to a cloud medical device software update agent (14) via said interface (34) and at least one second medical device software update agent (20) installed in at least one second medical device (16) of said plurality of medical devices (16); configured to receive 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 and a processor configured to install the authenticated medical device software update.

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

3. 3. The system of claim 2, further comprising: the cloud medical device software update agent (14) of a first medical device manufacturer; and another cloud medical device software update agent (14) of a second medical device manufacturer configured to connect to the cloud medical device software update agent (14) of the first medical device manufacturer via another Internet connection (30).

4. 4. The system of claim 3, wherein the cloud medical device software update agent (14) of the first medical device manufacturer and the another cloud medical device software update agent (14) of the second medical device manufacturer are configured to be connected to medical devices (16-1) of the first medical device manufacturer in the network of multiple medical devices (16) via a first Internet connection (30) and to medical devices (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 cloud medical device software update agent (14) further comprises: 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 that a given one of the software update agents (20) failed to relay a file from the cloud medical device software update agent (14) based on the received log (28); 3. The system of claim 2, further configured to: in response to identifying the failure, perform an action with respect to the given software update agent (20).

6. The first medical device (16) comprises: A file delivery table (46), instructions (54) for 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; a file delivery table (46) containing corresponding destination information (56) for the one or more files; A routing table (48), Identification (64) of assessable medical devices among the medical devices (16) in the network; The system of any one of claims 1 to 5, further comprising: a memory (38) configured to store a routing table (48) including corresponding routing information (66) of the assessable medical device.

7. 7. The system of claim 6, wherein the first medical device software update agent (20) is configured to forward 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) to the one or more medical devices (16) in the network based on the corresponding destination information (56) of the one or more files and the corresponding routing information (66) of the assessable medical device in the routing table (48).

8. The memory (38), a list of one or more direct neighbors (74) of the first medical device (16); and address information identifying the one or more direct neighbors in the network of medical devices.

9. The first medical device software update agent (20): populating the routing table (48) based on the list of the one or more direct neighbors (74); transmitting said routing table (48) to said one or more direct neighbors; receiving one or more routing tables (48) from said one or more direct neighbors; The system of claim 8, further configured to: expand the routing table (48) based on data contained in the received one or more routing tables (48), while removing one or more duplicate destination medical devices (16) based on consideration of shortest routes to the one or more duplicate destination medical devices (16).

10. 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); the processor (36) is configured to verify the additional digital signature and determine that the additional digital signature does not authenticate the additional medical device software update (26); The system of any one of claims 1 to 5, wherein the first medical device software update agent (20) is configured to block a file provided by the given medical device (16) based on the given medical device (16) failing to identify a lack of authentication of the additional medical device software update (26).

11. The first medical device software update agent (20): receiving an additional medical device software update (26) and an additional digital signature addressed to a given medical device (16) of the plurality of medical devices (16) from the cloud medical device software update agent (14) via the at least one second medical device software update agent (20); authenticating the received additional medical device software update (26) based on the additional digital signature; and and transferring the additional medical device software update (26) to the given medical device (16) in response to authenticating the additional medical device software update (26) based on the additional digital signature.

12. The system of any one of claims 1 to 5, wherein the first medical device software update agent (20) is configured to send a message to the 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 first medical device software update agent (20): receiving a software installation and / or software update log (28) from the medical device software (22) executing on the first medical device (16); and transferring the received log (28) 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 first medical device software update agent (20): receiving a log (28) from at least one of the plurality of medical devices (16); and transferring the received log (28) to the cloud medical device software update agent (14) via the at least one second medical device software update agent (20).

15. 1. A medical method comprising: Connecting a first medical device (16) to a network of a plurality of medical devices (16); executing medical device software (22); executing a first medical device software update agent (20); receiving (202) identification information (42) relating to the first medical device (16) from the medical device software (22) by a first medical device software update agent (20); transmitting (204) the identification information (42) by a first medical device software update agent (20) 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) of the plurality of medical devices (16); receiving (208) a medical device software update (26) 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), 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 installing (214) the authenticated medical device software update (26).

Images