Systems and methods to predict optimal period to communicate on updates, additional customer service and maintenance tasks of medical devices

Abstract

In maintenance scheduling, one or more inputs are received related to an upcoming maintenance or update session for a medical device. The one or more inputs are automatically analyzed to determine a proposed time for performing the upcoming maintenance or update session, and an indication of the proposed time is output on a user interface. In an example, a set of vendor- supplied software is loaded on the medical device, and the upcoming maintenance or update session for the medical device includes automatically performing an update of the set of vendor- supplied software loaded on the medical device. The medical device may be automatically scanned to identify third party software loaded thereon which is incompatible with a software update of the upcoming maintenance or update session, and instructions are output on the user interface to perform an update to the third-party software prior to the proposed time.

Description

SYSTEMS AND METHODS TO PREDICT OPTIMAL PERIOD TO COMMUNICATE ON UPDATES, ADDITIONAL CUSTOMER SERVICE AND MAINTENANCE TASKS OF MEDICAL DEVICESFIELD

[0001] The following relates generally to the medical device maintenance arts, medical imaging device maintenance arts, medical device predictive maintenance arts, and related arts.BACKGROUND

[0002] Medical devices such as computed tomography (CT) scanners, magnetic resonance imaging (MRI) scanners, positron emission tomography (PET) scanners, and other medical imaging devices are mechanically complex and highly computerized. As just one example, an MRI scanner may include thousands of systems, subsystems, and individual components, with automated operation of the patient support bed, magnetic field gradient coils, radio frequency (RF) coils, and other hardware, along with software for reconstructing and displaying acquired MRI images. The maintenance of such complex medical devices is often outsourced to the device vendor since hospitals typically do not have the requisite expertise. In addition to maintenance, the vendor party may occasionally offer software or hardware updates to improve the capabilities of the medical device, or for another reason such as compliance with new or revised governmental regulations. Scheduling such maintenance or updates can be challenging, as an MRI or other complex medical device commonly handles a heavy workload. The maintenance or update should minimally interfere with that workload.

[0003] Scheduling to install software or hardware maintenance or updates of medical devices (either remotely or on-site, depending on the particular maintenance or update) is typically an ad hoc process in which the vendor and customer discuss the maintenance or update and mutually arrive at a suitable time. This can be frustrating for the customer as it takes time for the customer to negotiate a suitable time, and the vendor may push to have the maintenance or update performed at a time that may be inconvenient for the customer. The problem can be further complicated if the maintenance or update requires action by the customer. For example, the customer may need to update third party software to ensure that it is not adversely affected (e.g., broken) by a software update pushed by the vendor. Such third-party updates, if not performed by the vendor (or at least coordinated with the vendor) can be unnecessary, or in some instances canlead to degradation of performance of the medical imaging device with potentially adverse impact on efficiency or patient care.

[0004] The following discloses certain improvements to overcome these problems and others.SUMMARY

[0005] In one aspect, a non-transitory computer readable medium stores instructions readable and executable by at least one hardware processor to: receive one or more inputs related to an upcoming maintenance or update session for a medical device; analyze the received one or more inputs to determine a proposed time for performing the upcoming maintenance or update session; and output, on a user interface (UI), at least an indication of the determined proposed time. In some embodiments, the one or more inputs include at least a software bill of materials (SBOM) of the medical device to be updated.

[0006] In another aspect, a non-transitory computer readable medium storing instructions readable and executable by at least one hardware processor to perform an update method for a set of vendor-supplied software loaded on a medical device, the update method comprising: automatically scanning the medical device and / or automatically analyzing a software bill of materials of the medical device to identify third party software loaded on the medical device which is not included in the set of vendor-supplied software loaded on the medical device; automatically comparing the identified third party software with software dependency data to identify at least one dependency between the identified third party software and the set of vendor-supplied software loaded on the medical device; performing a remedial action in response to determining, based on the identified at least one dependency, that the identified third party software is incompatible with an update to the set of vendor-supplied software loaded on the medical device; and after performing the remedial action, performing the update to the set of vendor-supplied software loaded on the medical device.

[0007] In another aspect, an update method is disclosed for a set of vendor-supplied software loaded on a medical device, the update method comprising: receiving one or more inputs related to an upcoming maintenance or update session for a medical device; analyzing the received one or more inputs to determine a proposed time for performing the upcoming maintenance or update session and / or third party software loaded on the medical device that is incompatible with the upcoming maintenance or update session; outputting, on a user interface (UI) displayed on anelectronic processing device operable by a customer of the medical device, the proposed time and / or instructions for updating the third party software that is incompatible with the upcoming maintenance or update session.

[0008] One advantage resides in improving customer satisfaction by providing communication on updates or maintenance tasks during a time window that is convenient for the customer, instead of pushing communications without taking care of the condition of the customer (e.g., load of the institution, other devices interrelated to the device where to perform the update, etc.)

[0009] Another advantage resides in ensuring that the customer performs the maintenance or upgrade tasks on time.

[0010] Another advantage resides in ensuring that the upgrade tasks of vendor software and third-party software patches are compliant to the security and safety standards.

[0011] A given embodiment may provide none, one, two, more, or all of the foregoing advantages, and / or may provide other advantages as will become apparent to one of ordinary skill in the art upon reading and understanding the present disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The disclosure may take form in various components and arrangements of components, and in various steps and arrangements of steps. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the disclosure.

[0013] FIGURE 1 diagrammatically illustrates an illustrative system for determining a maintenance or update session for servicing a medical device in accordance with the present disclosure.

[0014] FIGURE 2 shows exemplary flow chart operations of the system of FIGURE 1.

[0015] FIGURE 3 presents a nonlimiting illustrative example of a timeline for an upgrade.DETAILED DESCRIPTION

[0016] The following discloses a system for proactively analyzing available information to predict an optimal time for performing the maintenance or update. The illustrative approach uses a Bayesian model receiving various inputs, such as the lead time, seasonal patterns of usage of the affected medical device, the maintenance complexity or size of the update (large or major updates usually call for a longer lead time than minor updates), and various interdependencies ofthe medical devices of a fleet of medical devices (for example, if updating one medical device will also require another related medical device that also has a pending update to be taken offline then it may be beneficial to perform both updates at the same time). The illustrative Bayesian model accounts for various specified priors that limit when the maintenance or update can be performed, and likelihoods that probabilistically account for various possible events. While a Bayesian model is employed as an illustrative example, other approaches can be used for analyzing the received inputs to determine a proposed time for performing the upcoming maintenance or update session, such as Monte Carlo simulation, a suitably trained artificial neural network (ANN), or so forth.

[0017] Some embodiments also provide approaches to handle the impact of third-party software. Such third-party software can take various forms, such as third-party software that is installed by the vendor, and / or third-party software that is installed by the customer. Third-party software can be adversely impacted by a software update if it is incompatible with that update (or vice versa, i.e., the update is incompatible with the third-party software). Third-party software can also be adversely impacted by a hardware update, for example if the third-party software does not include suitable programming for handling the updated hardware and / or if the third-party software needs to be reconfigured to work with the updated hardware. To handle such cases, a scan of the controller (or other microprocessor-based component of the medical system) can be performed to automatically identify any relevant third party software that is installed, and this can be cross- referenced with a database of software dependencies to determine if any of the installed third party software will be affected by the vendor update. Additionally or alternatively, if a software bill of materials (SBOM) is available for the medical imaging device this can provide information on the software installed on the medical imaging device. In the case of third-party software installed by the vendor, such dependencies can be handled directly by the vendor. In the case of third-party software installed by the customer, if the customer will need to perform update of the third party software ahead of the vendor update, then this can be taken into account in the scheduling, and the customer can be notified to update of the third-party software before the vendor update is performed. In some cases, the handling of third-party software may include removal of the third- party software if it is wholly incompatible with the upcoming vendor update, and optional replacement by different software to provide commensurate functionality. In another aspect, if the customer is planning to update third-party software in a way which is incompatible with thevendor-supplied software, then this can be automatically identified and the customer advised to not perform the third-party software update.

[0018] The following focuses on a scheduler including the capability to predict and recommend an optimal time for performing a maintenance or update. The scheduler may include a vendor user interface (UI) that enables a maintenance or update to be entered for scheduling. This triggers the scheduler to analyze the received inputs to determine a proposed time for performing the upcoming maintenance or update session and thereby output one or more proposed time windows for performing the maintenance or update that the scheduler predicts would be most convenient for the customer. A customer-facing UI (which could be an automated email generator, for example) then informs the customer of the maintenance or update to be scheduled, and also suggests the proposed time window(s) for doing so. The customer-facing UI enables the customer to accept the proposal or to counter-propose a different time window. In this way, the scheduler efficiently facilitates setting up a good time for performing the maintenance or update.

[0019] With reference to FIGURE 1, an illustrative scheduler system 100 implemented on a server computer 111 or the like provides for scheduling maintenance or update of a device 120 (e.g., a medical imaging device - also referred to as a medical device, an imaging device, imaging scanner, and variants thereof) is diagrammatically shown. By way of some non-limiting illustrative examples, the medical imaging device 120 to be scheduled to undergo service may be a magnetic resonance imaging (MRI) scanner, a computed tomography (CT) scanner, a positron emission tomography (PET) scanner, a gamma camera for performing single photon emission computed tomography (SPECT), an interventional radiology (IR) device, or so forth. (More generally, embodiments of the disclosed scheduler can be applied in conjunction with scheduling of maintenance or update of any type of complex computerized device, e.g., the approach could be applied to schedule maintenance or update of a commercial airliner, radiation therapy device, or so forth). As shown in FIGURE 1, the scheduler 100 includes, or is accessible by, a vendor device 102 that may for example be a workstation or electronic processing device used by an RSE. The vendor device 102 is operated by an employee or other agent of a vendor or other service provider (for example, by a service engineer, a customer service representative, or so forth), and may for example be a desktop computer or a portable device such as a notebook computer. As another nonlimiting illustrative example, the vendor device 102 may be a mobile device such as a cellular telephone (cellphone) or tablet computer.

[0020] The vendor device 102 includes a display 105, at least one user input device 103 such a mouse, keyboard, or touchscreen. The vendor device 102 further includes an electronic processer 101 and non-transitory storage medium 107 (internal components which are diagrammatically indicated in FIGURE 1). The non-transitory storage medium 107 stores instructions which are readable and executable by the electronic processor 101 for interfacing the vendor (e.g., a service engineer, customer service representative, or other agent of the vendor) with the scheduler system 100. The vendor device 102 also includes a communication interface 109 to communicate with the server or processing device 111, which implements the computational aspects of the scheduler system 100. Such communication interfaces 109 include, for example, a wired and / or wireless Ethernet interface (e.g., in the case in which the service device 102 is a RSE workstation); or in the case in which the service device 102 is a portable FSE device the interface 109 may be a wireless Wi-Fi or 4G / 5G interface or the like for connection to the Internet and / or an intranet. Some aspects of the scheduler system 100 may also be implemented by cloud processing or other remote processing (that is, the server computer 111 may be embodied as a cloud-based computing resource comprising a plurality of interconnected servers).

[0021] In illustrative FIGURE 1, the scheduler 100 is implemented and / or owned by the imaging device vendor or leased by the vendor from a cloud computing service provider. The scheduler 100 provides an interface between the vendor, for example represented in FIGURE 1 by the vendor device 102, and a customer, for example represented in FIGURE 1 by a customer device 102c. The scheduler 100 facilitates scheduling of updates or maintenance of the medical device 120 by the vendor at dates that are acceptable to the customer. The scheduler 100 may optionally additionally or alternatively provide a ticketing system or the like via which the customer (e.g., via the customer device 102c) can manually open a ticket for an open issue that may lead to scheduling of updating or maintenance of the medical device 120.

[0022] In some embodiments, the scheduler 100 maintains or has access to a software bill of materials (SBOM) 128 for the medical device 120. The SBOM 128 stores information on the inventory of software components (e.g., software packages, programs, modules, and / or so forth) installed on the medical device 120, along with metadata (and / or links to metadata) about the software components. The software component metadata may include, for example, software component vendor and / or version information, software component licenses, software security information, interrelation information between software components, and / or the like. In somenonlimiting illustrative embodiments, the SBOM 128 may be stored in a software package data exchange (SPDX) compatible format, which facilitates integration of such metadata across software components and vendors. The SBOM 128 in some embodiments is available to the scheduler 100, in which case the SBOM 128 may provide relevant information for scheduling of updates or maintenance of the medical device 120 by the vendor. For medical devices (e.g., medical device 120), it is contemplated to extend the metadata stored in the SBOM 128 to include metadata on aspects such as patient privacy and / or safety. For example, the SBOM 128 may include metadata flagging any software component that could access or transfer patient-related information in nonconformance with the Health Insurance Portability or Accountability Act (HIPAA) in the United States, or in nonconformance with patient privacy regulations in effect in other jurisdictions. As another example, the SBOM 128 may include metadata flagging any software component that could change the operating parameters of the medical device 120 in a way that could impact patient safety, such as a software component that can adjust the settings of an X-ray source in the case of a CT or other X-ray imaging device, or a software component that can adjust the RF power applied to the patient in the case of an MRI.

[0023] The optional SBOM 128 may be generated and / or maintained in various ways. In one embodiment, the SBOM 128 is supplied to the customer when the medical device 120 is delivered to the customer. Thereafter, the SBOM 128 can be manually updated by the vendor and / or customer when a change is made to the installed software base of the medical device 120. Vendor supplied software updates may also automatically update the SBOM 128. To handle third party software components added by the customer, these can be added manually by the customer (e.g., if the SBOM 128 is compliant with an open standard such as SPDX), and / or a periodic scan of the controller (or other microprocessor-based component of the medical device 120) can be performed to automatically identify any third party software that is installed and add this information to the SBOM 128. Updates to the SBOM 128 should be performed whenever software is added or removed and whenever a software update (security or functional) is performed. An advantage of maintaining the SBOM 128 for each medical device 120 is that in the case of a large customer (e.g., a large hospital system) the customer may have numerous medical devices with different installed software and / or different software versions. Thus, the SBOM 128 ensures the scheduler 100 has accurate information about the specific medical device(s) being updated.

[0024] The customer device 102c includes an electronic processer 101c and non-transitory storage medium 107c (internal components which are diagrammatically indicated in FIGURE 1), a display 105c, and at least one user input device 103c such a mouse, keyboard, or touchscreen. The non-transitory storage medium 107c stores instructions which are readable and executable by the electronic processor 101 for interfacing the customer (e.g., a radiology department administrator in the case of a medical imaging device 120) with the scheduler system 100. The customer device 102c includes a wired and / or wireless communication interface 109c to communicate with the server computer 111 of the scheduler 100. In some embodiments, the SBOM 128 may be accessible by the customer via the customer device 102c. In such cases, the customer may intend to perform an update to third party software installed on the medical device 120, for example to apply a security update. In such instances, the customer may access the scheduler 100 to schedule the third party update, which then triggers the scheduler 100 to analyze the SBOM 128 and the customer-intended software update to determine whether the update should be performed and, if so, whether any update to the vendor-supplied software should be performed in coordination with the customer. If the customer fails to inform the vendor via the scheduler 100 ahead of performing the third party software update, then this unauthorized (by the vendor) update may be detected by an automated periodic scan of the installed software base of the medical device 120 (if such automated scanning is performed) or may be detected if the user updates the SBOM 128 to reflect the customer-performed update. Again, this triggers the scheduler 100 to analyze the update or updated SBOM 128 to determine whether the (in this case already-performed customerside software update has introduced any problems, and if so can advise the customer of how to remedy such problem (e.g., recommending rolling back the update, or recommending updating of the vendor-supplied software as might be appropriate).

[0025] In the case of a vendor-performed update, the vendor device 102 is programmed to interact with the scheduler 100 to provide inputs to set up for the upcoming maintenance or update session for the medical device 120. However, the operator of the vendor device 102 typically does not know a priori when such an upcoming maintenance or update session can be conveniently scheduled from the viewpoint of the customer. To schedule the maintenance or update session, the scheduler 100 analyzes the received one or more inputs, optionally along with information about the customer and / or the medical device 120 (e.g., obtained from the SBOM 128), to determine a proposed time for performing the upcoming maintenance or update session. This proposed time isoutput on a user interface (UI) 140 of the vendor device 102, and typically also on a UI 144 of the customer device 102c. Additionally, if the scheduler 100 determines that customer-installed third party software needs to be updated (to a different version, or removed altogether) in conjunction with the vendor-performed update, then instructions on such third party software updates can be provided to the customer via the UI 144 (e.g., in the form of an instruction such as: “Medical device — has software — installed. This software must be updated prior to the time of the upcoming vendor-performed software update.”). These output may occur asynchronously - for example, the output of the proposed time may be presented immediately upon determination at the UI 140 at the vendor device 102, but may only be presented at a later date on the UI 144 of the customer device 102c, such as the next time the radiology department administrator or other customer agent logs into the scheduler 100. As another nonlimiting example, the output may be sent to the vendor agent and customer agent via email and thus be presented whenever the respective agents next read their respective email accounts.

[0026] The server 111 implementing the scheduler 100 is equipped with non-transitory storage medium 127 (internal components which are diagrammatically indicated in FIGURE 1). While a single server computer is shown, it will be appreciated that the backend 110 may more generally be implemented on a single server computer, or a server cluster, or a cloud computing resource comprising ad hoc-interconnected server computers, or so forth. Furthermore, while FIGURE 1 shows a single medical imaging device 120, more generally the database backend 110 will receive log data from many medical imaging devices (e.g., tens, hundreds, or more imaging devices) and performs the disclosed processing for each such medical imaging device. Still further, it will be appreciated that there may be multiple instances of the vendor device 102 enabling various service engineers, customer representatives, and / or other vendor agents to access the scheduler 100, and likewise there may be multiple instances of the customer device 102c enabling various customer representatives, optionally from multiple different customers (e.g. different hospitals), to access the scheduler 100. In the illustrative embodiment, the storage medium 127 of the server 111 is shown as storing the SBOM 128 of the medical device 120. However, in other embodiments the SBOM 128 may be stored at the medical device 120, at a server computer of the customer (not shown) - in such cases, the SBOM 128 (or relevant metadata on the software of the medical device 120 contained in the SBOM 128) is suitably transferred to the storage medium 127 (at least) when that information is to be consumed by the scheduler 100. The storage medium 127of the scheduler 100 may also maintain a database 129 of third party software components that are known or credibly expected to be deployed on the medical device 120, along with metadata indicative of dependencies between the various third party software components and the set of vendor-supplied software loaded on the medical device 120. This information may be stored with versioning data, for example the database 129 may indicate that a given third party software component of versions 2.9 and lower is incompatible with vendor-supplied software of version 5.0 and above; while versions 3.0 and above of the third party software component are compatible with vendor-supplied software of version 5.0 and above. In some embodiments, when a third-party software component is added to the SBOM 128 of the medical device 120 then this database 129 is searched to automatically identify any incompatibilities and such incompatibility information is copied into the SBOM 128.

[0027] With continuing reference to FIGURE 1, the non-transitory computer readable medium 127 stores a model 130 configured to determine a proposed time for performing an upcoming maintenance session or an upcoming maintenance session for the medical device 120. For example, a service engineer, customer service representative, or other vendor agent provides inputs via the vendor device 102 related to the upcoming maintenance session or upcoming maintenance session, which are received and analyzed by the model 130. The provided inputs may also include the SBOM 128 of the medical device 120 to be updated, and / or analogous information on the installed software of the medical device 120 obtained by an automatic scan of the installed software. In some embodiments, the model 130 comprises a Bayesian model. The model 130 includes one or more conditions that limit when the maintenance or update session can be performed. These conditions may be different for different customers and may be parameters of the Bayesian or other model 130. While a Bayesian model is employed as an illustrative model 130, other types of models can be used for analyzing the received inputs to determine a proposed time for performing the upcoming maintenance or update session, such as Monte Carlo modeling, a suitably trained artificial neural network (ANN), or so forth.

[0028] The non-transitory storage medium 127 further stores instructions executable by the electronic processor 113 of the backend server 111 to perform a scheduling method 200 for scheduling updating of vendor-supplied software 132 loaded on the medical device 120. In other embodiments, maintenance of hardware, or combined hardware maintenance and software updating, sessions may be similarly scheduled. For example, an upcoming maintenance or updatesession for the medical device 120 includes performing an update of the set of vendor-supplied software 132 loaded on the medical device 120. In some embodiments, the medical device 120 can include a controller of the medical device (e.g., an imaging device controller of a medical imaging device) and the set of vendor-supplied software 132 may be loaded on such a controller. The imaging device controller is considered a component of the imaging device herein.

[0029] In some embodiments, the scheduler 100 may also account for any third party software 134 that may be loaded on the medical device 120, which is not included in the set of vendor-supplied software 132 loaded on the medical device 120. The third-party software 134 may have been previously installed by the vendor or may have been installed by the customer. As some nonlimiting illustrative examples, the third party software 134 may be control software for add-on or optional hardware components of the medical device 120 (for example, such a component might be a local radio frequency coil used in conjunction with a magnetic resonance imaging scanner, a camera used to provide remote monitoring of the medical imaging session, or another type of additional sensor, or so forth). As another example, the third-party software 134 may be information handling software, for example enabling interfacing of the medical imaging device 120 with a Picture Archiving and Communication System (PACS) that is not supplied by the vendor of the medical imaging device 120 as a specific example. As another example, the third- party software 134 may be advanced image processing software or machine learning (ML) based image analysis software that runs on the controller of the medical imaging device 120. Such third- party software 134, while not part of the vendor-supplied software 132 to be updated, may nonetheless be adversely affected by (or may adversely affect) the upcoming update of the vendor- supplied software 132. For example, the vendor software update could break a dependency of the third-party software 134 on the vendor-supplied software 132, or vice versa. Such dependencies may, by way of non-limiting illustrative example, enable transfer of images acquired by the medical imaging device 120 under control of the vendor-supplied software 132 to the third-party software 134 for image processing, ML-based image analysis, transfer to the PACS, or so forth. As disclosed herein, the scheduler 100 enables detection of such affected third party software 134, and / or such third party software may be identified in the SBOM 128 of the medical device 120, and the scheduler 100 ensures that any adverse impact on (or by) the third party software 134 is handled in a timely manner, for example by coordinating updating of the third party software with the customer prior to performing the vendor software update.

[0030] With continuing reference to FIGURE 1 and further reference to FIGURE 2, an illustrative embodiment of the scheduling method 200 executable by the electronic processor 113 is diagrammatically shown as a flowchart. In some examples, the scheduling method 200 may be performed at least in part by cloud processing.

[0031] To begin the method 200, at an operation 202, one or more inputs related to the upcoming maintenance or update session for the medical device 120 are input by the vendor agent via the vendor device 102, which are received at the server 111. Additionally or alternatively, the inputs might be received from the customer device 102c, for example if the scheduler 100 maintains a ticketing system via which the customer can directly requires maintenance of software updates. Additionally or alternatively, the inputs might be received via an automated source, such as the SBOM 128 of the medical device 120. As another example of an automated input source, the scheduler 100 may be integrated with a machine logging software that receives occasional uploads of log data from the medical device 120. Automated log data analysis may extract workload trends from the machine log data, and thereby extract historical patterns of usage of the medical device 120 including variations such as reduced usage during certain holidays or seasons of the year, reduced usage on weekends, and / or so forth. As another example, the scheduler 100 may be integrated with a human resources (HR) department system of the customer (e.g. hospital), and may from this data source determine historical trends in staffing levels at the hospital. This type of information could be useful inputs to the model 130 to facilitate scheduling when the workload of the medical device 120 is low, and / or to facilitate scheduling when appropriate hospital staff are available to assist in or oversee the upcoming maintenance or software update. Still further, the inputs could include inputs related to other upcoming maintenance or software updates of the medical device 120 or of other similar medical devices at the same site (e.g., same hospital). This type of information could be useful inputs to the model 130 to facilitate beneficial concurrent scheduling of similar maintenance or updates to enable for example a single service engineer visit to perform the multiple maintenance and / or software update tasks; or, conversely, to avoid concurrent scheduling of different maintenance or update tasks that would interfere with each other. (For example, if the medical device 120 needs to be online for a certain software update but must be taken offline for certain hardware maintenance, then those tasks are not compatible and would conflict with each other. The input(s) in general can include, for example, one or more of a maintenance or update session lead time, seasonal patterns of usage of the medical device 120,a maintenance complexity or size of the update, one or more interdependencies of medical devices in a fleet of medical devices undergoing multiple maintenance or updates processes, and so forth.

[0032] At an operation 204, the received input(s) are analyzed to determine a proposed time for performing the upcoming maintenance or update session. In some embodiments, this analysis can be performed by the model 130. The analysis operation 204 can be performed in a variety of manners. In some embodiments, the upcoming maintenance or update session for the medical device 120 includes performing an update of the set of vendor-supplied software 132 loaded on the medical device 120.

[0033] In some embodiments, the analysis operation 204 can include automatically identifying third party software 134 loaded on the medical device 120 which is not included in the set of vendor-supplied software 132 loaded on the medical device 120. The identified third-party software 134 is compared with software dependency data stored in the non-transitory storage medium 127 to automatically identify any dependencies between the identified third-party software 134 and the set of vendor-supplied software 132. The model 130 then automatically determines, based on the identified dependencies, whether the update of the set of vendor-supplied software 132 to be performed during the upcoming maintenance or update session adversely affects the identified third-party software 134. As used herein, “adversely affects” can include, for example, a broken dependency, loss of functionality of the third-party software 134, interference of the vendor-supplied software 134 by the third-party software, or so forth. In some examples, in response to a determination that the update of the set of vendor-supplied software 132 adversely affects the identified third-party software 134, an update of the identified third-party software 134 can be added to the upcoming maintenance or update session (i.e., a remedial action). In other examples, in response to a determination that the update of the set of vendor-supplied software 132 adversely affects the identified third-party software 134, a request directed to a customer to perform an update of the identified third-party software 134 prior to the upcoming maintenance or update session can be output.

[0034] At an operation 206, at least an indication of the determined proposed time is output on a graphical user interface (GUI) 140, 144 displayed on the display device 105 of the service device 102. In some examples, the GUI can include the vendor UI 140 displayed on the vendor device 102 operable by a vendor of the medical device 120, and / or the customer UI 144 displayedon the customer device 102c. The vendor GUI 140 and / or customer GUI 144 presents one or more proposed time windows for performing the upcoming maintenance or update session.

[0035] At an output operation 208 (which may be in parallel with or integrated with the output operation 206), if any third party software that is maintained by the customer is identified as adversely affecting, or being adversely affected by, the upcoming vendor-performed update, then in the operation 208 suitable instructions are provided to the customer to perform customer updating of the third party software. The instructions might instruct the customer to update the third-party software from an older version that is incompatible with the upcoming vendor software update to a more recent version known to be compatible with the vendor updated software. In some instances, the instruction for customer updating may be to remove the customer-maintained third-party software if it is incompatible with the upcoming vendor update and cannot be made compatible with that update. In a variant situation, if the upcoming vendor update would render the third-party software unnecessary (for example, because the vendor update will provide functionality equivalent to that provided by the third-party software) then again, the operation 208 may instruct the customer to remove the now-redundant third-party software.

[0036] In some embodiments, the scheduling method 200 may be extended to further include an operation 210 of actually performing the scheduled upcoming maintenance or update session at the proposed time that was determined in the operation 204. For example, if the upcoming maintenance or update session constitutes updating of vendor-supplied software 132 loaded on the medical device 120, then this may be performed automatically in the operation 210. Some types of maintenance could also be performed automatically or semi-automatically in the operation 210, such as performing detector calibration for a computed tomography (CT) or positron emission tomography (PET) scanner using imaging data acquired of an imaging phantom, a point radiation source, or an empty scanner (i.e., an air scan or air calibration). In other embodiments, the scheduled maintenance or update session may be performed manually, for example if it entails replacing physical hardware of the medical imaging device.EXAMPLES

[0037] Some further illustrative embodiments of the scheduler system 100 are described in more detail below. In existing systems in medical institutions, there can be a lead time associated to any of these tasks that can vary (e.g. a software update can be done in a day, whileupgrading or replacing a hardware component can take longer due to other processes involved such as purchasing, shipping, installment, etc.).

[0038] There are seasonal patterns for the end-customers, given that certain periods are busier, admission of in-house patients are done sometimes on a fixed basis, etc. This piece of information needs to be taken into account according to each end-user to adjust the maintenance tasks to the periods where the load is lower, so that these tasks doesn’t affect the normal usage of the device. In addition, the time when the end-user needs to be communicated regarding the upcoming update or maintenance task is correlated to the size of the update or maintenance task (e.g., bigger maintenance tasks which needs to take several days needs to be planned quite in advance). Moreover, in some situations it might be convenient to perform the updates or maintenance tasks on multiple devices, if such devices do not need an urgent update to continue functioning normally. This might be convenient for the end-user to perform these tasks on multiple devices during the same period of time. Some medical devices 120 can be interdependent, and therefore, the updates or maintenance tasks need to be planned to not disturb the normal functioning of such medical devices. There may be both hardware and software patches added by third parties that compromise future patient safety or security aspects of procedures to be performed. Some medical devices 120 can have higher downtime and restart cost than other devices, e.g. restarting an MRI can be quite expensive. There is a predictive maintenance and software upgrades module in place running, where historical data has been collected on past upgrades and maintenance tasks performed.

[0039] To predict the most suitable time to communicate an update or maintenance task, the scheduler system 100 uses a Bayesian approach can be used. There are two types of signals in the Bayesian approach: priors and likelihoods. Priors are given conditions that limit when the update or maintenance task can be performed, such as when the end-user does not want to perform a maintenance or update task due to high load of the medical device. Other prior signals are the lead time associated to each maintenance task (software vs hardware components), the size of the maintenance task or the interdependencies of medical devices. More generally, the priors may include given conditions such as a load of the medical device, a size of the maintenance task, or the (one or more) interdependencies of the medical devices Likelihoods are a probability of observing data coming from a specific scenario. Some examples of this are the probability of a component to fail or behaving outside control limits or the probability of a device being in highload for a certain time, given the historical log data extracted from the medical device. Such variables can be modelled (i.e., for a single device) as shown in FIGURE 3. As shown in FIGURE 3, the variables can include t communication is a time to perform the communication of the upgrade of maintenance task; T upgrade is a period to perform the upgrade, function of the size of the upgrade; T preparation is a time to prepare the execution of the upgrade, time in between the announcement and start of execution of the upgrade; urgency is a value or ranking provided by the SW supplier together with the medical staff, Costs Downtime is a value provided by the medical staff based on the importance of having the device continuously running, seasonality and load are values at a given time, based on the analysis of historical log data; and X trigger is a signal or variable triggering the need of an update based on the anomaly detection of tracked device’s parameters, which can also influenced by the load and seasonality values of the given period.

[0040] To perform these functions, the scheduler system 100 is configured to perform (i) a temporal analysis of usage of the medical device 120 (based on the machine log data) to understand the seasonality patterns of such device, (ii) an anomaly detection of the values of the components of the medical device 120 (based on the machine log data) to identify when a component is behaving out of the control limits and thus, might need a replacement; a process of mapping of fleet of medical devices 120 and their interdependencies to define when an update of several devices can be scheduled together or when an update or maintenance task will influence an interdependent medical device; a mapping process of all devices involved and mapping of the software bill of materials; a downtime analysis of medical devices (based on the machine log data) to identify which medical devices fail more often and the associated costs of that downtime and restart of the device, in which a root cause analysis approach can be used to understand why certain devices fail; a process to check if the updates and maintenance tasks are performed in the time window proposed. (If this is not the case, analysis and discussion with the end-user to adjust the proposed time window); provide reminders and notifications when an urgent update or maintenance task has not been yet scheduled; and overruling system which gives the end-user (administrator of fleet of devices) the final decision-making power to modify when an update or maintenance task will be performed (e.g. unexpected situations like increase in the load of a device); a feedback retrieval process of an end-user's experience to identify areas of improvement and communicate the updates or maintenance task in a more suitable time. The proposed solutioncan be also scoped for managing a fleet of devices, taking into account the independency mapping of such devices.

[0041] In some embodiments, third party software patches that interact with the vendor software updates are accounted for. Ensuring that these third-party patches are updated in time and compliant to the security and safety standards is key to preserving patients’ safety and data security of the software that the vendor delivers to the end customers. In order to provide an update to the end-customer, the vendor suitably takes into account upgrades from third party software modules and its compatibility.

[0042] The optional bill of material of the software modules / patches 128, if available, helps in understanding the independencies of the software modules, and allows the scheduler 100 to check the security, privacy policies and vulnerabilities of such third party modules, for example with reference to the database 129 of third party software components and dependencies between the various third party software components and vendor-supplied software. Compliance to the security and privacy standards is key to ensure the patient’s data safety. These steps can be followed to prevent vulnerabilities in vendor upgrades, such as detection and listing of third-party software modules. If information on the third-party software component is not available in the database 129, then the scheduler 100 can issue a request for information to the customer or to the third-party supplier (for example, if supplier contact information is included in the metadata on the software component in the BSOM 128). Remediation if third party software has a compatibility issue may include, for example, querying for new upgrades in case of open source modules, and determining if security and vulnerability are at stake for the given upgrade. For example, a query request whether the third-party software component is operative for importing from external (e.g., open source) libraries.

[0043] In order to prevent third party modules not authorized to interact with vendor software, permission and access roles may in some embodiments be checked before performing an upgrade or installation of third-party module or patch. Only authorized users (e.g., IT staff from the hospital) will be able to perform the needed update, after assessing the security and vulnerability policies of such update. Depending on the login credentials it could be determined who is allowed to give the permissions. The third-party modules can be further characterized by feature-specific permissions requested (e.g., whether the module can access sensitive personal information, requests network communication capability, etc.). The device software can be‘tainted’ or be provided specific security vulnerability status and the final trust level of the device in the fleet determined accordingly.

[0044] Given that open source third party modules are not committed to communicating updates (as commercial suppliers are), a check with these modules may be done to determine whether the software is well maintained and periodic updates are provided. An analysis of open issues versus resolved issues can be a good indicator of whether the third-party software component is well maintained (such open source maintenance information can be retrieved from public databases, e.g., Github issue count statistics can be obtained via https: / / github.com / MorrisJobke / github-issue-counter).

[0045] In some embodiments, the scheduler system 100 can be applied to a fleet of medical devices 120. For example, larger hospital or medical facility systems can have numerous medical devices 120, all running different software versions or applications. The analysis operation 204 can include coordinating updates of these different software versions or applications across the medical devices 120 in the fleet to account for such interdependencies of the medical devices of the fleet. In some examples, the analysis operation 204 can include detecting any security updating or patching that was performed on the medical devices 120 in the fleet, and providing instructions in the operation 208, if appropriate, to instruct the customer to perform any updates to customer- maintained third-party software.

[0046] In some embodiments, the SBOM 128 for each medical device 120 can be implemented to include metadata indicating how software patching can affect an overall performance of the scheduler system 100. For example, if customers of the medical devices 120 have access to SBOMs, they may endeavor to have third party patching programs, some of which may alter the performance of the scheduler system 100 as they are not actually needed as the patching is handled in the vendor software or can be irrelevant to individual devices 120 in the fleet. Third parties may provide patching services without really knowing whether the patching can have an effect on the software of each medical devices 120. To remedy these issues, the analysis operation 204 can include scheduling the updates of these patches to be coordinated with updates that have been reviewed and approved by the vendor, for example via the operation 208.

[0047] A non-transitory storage medium includes any medium for storing or transmitting information in a form readable by a machine (e.g., a computer). For instance, a machine-readable medium includes read only memory ("ROM"), solid state drive (SSD), flash memory, or otherelectronic storage medium; a hard disk drive, RAID array, or other magnetic disk storage media; an optical disk or other optical storage media; or so forth.

[0048] The methods illustrated throughout the specification, may be implemented as instructions stored on a non-transitory storage medium and read and executed by a computer or other electronic processor.

[0049] The disclosure has been described with reference to the preferred embodiments. Modifications and alterations may occur to others upon reading and understanding the preceding detailed description. It is intended that the exemplary embodiment be construed as including all such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.

Claims

CLAIMS:

1. A non-transitory computer readable medium (107, 127) storing instructions readable and executable by at least one hardware processor (101, 113) to: receive one or more inputs related to an upcoming maintenance or update session for a medical device (120), optionally wherein the one or more inputs include at least a software bill of materials (SBOM) of the medical device to be updated; analyze the received one or more inputs to determine a proposed time for performing the upcoming maintenance or update session; and output, on a user interface (UI) (140, 144), at least an indication of the determined proposed time.

2. The non-transitory computer readable medium (107, 127) of claim 1, further storing a model (130), wherein the analysis of the received one or more inputs to determine the proposed time for performing the upcoming maintenance or update session uses the model.

3. The non-transitory computer readable medium (107, 127) of claim 2, wherein the model (130) comprises a Bayesian model.

4. The non-transitory computer readable medium (107, 127) of either one of claims 2 and 3, wherein the model (130) includes one or more conditions that limit when the maintenance or update can be performed, wherein the one or more conditions include at least one of (i) a load of the medical device, (ii) a size of the maintenance task, and / or (iii) one or more interdependencies of the medical device on other medical devices of a fleet of medical devices.

5. The non-transitory computer readable medium (107, 127) of any one of claims 1-4, wherein a set of vendor-supplied software (132) is loaded on the medical device (120), and the upcoming maintenance or update session for the medical device includes automatically performing an update of the set of vendor-supplied software loaded on the medical device.

6. The non-transitory computer readable medium (107, 127) of claim 5, wherein the instructions are readable and executable by the at least one hardware processor (101, 113) to further: automatically identify third party software (134) loaded on the medical device (120) which is not included in the set of vendor-supplied software (132) loaded on the medical device; automatically compare the identified third-party software with software dependency data to identify any dependencies between the identified third-party software and the set of vendor-supplied software loaded on the medical device; and automatically determine, based on the identified dependencies, whether the update of the set of vendor-supplied software loaded on the medical device to be performed during the upcoming maintenance or update session adversely affects the identified third-party software.

7. The non-transitory computer readable medium (107, 127) of claim 6, wherein the instructions are readable and executable by the at least one hardware processor (101, 113) to further: in response to a determination that the update of the set of vendor-supplied software (132) loaded on the medical device (120) to be performed during the upcoming maintenance or update session adversely affects the identified third party software (134), add an update of the identified third party software to the upcoming maintenance or update session.

8. The non-transitory computer readable medium (107, 127) of claim 6, wherein the instructions are readable and executable by the at least one hardware processor (101, 113) to further: in response to a determination that the update of the set of vendor-supplied software (132) loaded on the medical device (120) to be performed during the upcoming maintenance or update session adversely affects the identified third party software (134), output a request directed to a customer to perform an update of the identified third party software prior to the upcoming maintenance or update session.

9. The non-transitory computer readable medium (107, 127) of any one of claims 1-8,wherein the UI (140, 146) comprises a UI (140) displayed on an electronic processing device (102) operable by a vendor of the medical device (120), the UI including one or more proposed time windows for performing the upcoming maintenance or update session.

10. The non-transitory computer readable medium (107, 127) of any one of claims 1-9, wherein the UI (140, 146) comprises a UI (146) displayed on an electronic processing device (144) operable by a customer of the medical device (120), the UI including one or more proposed time windows selectable by the customer to schedule the upcoming maintenance or update session.

11. The non-transitory computer readable medium (107, 127) of any one of claims 1-10, wherein the inputs include one or more of a maintenance or update session lead time, seasonal patterns of usage of the medical device (120), a maintenance complexity or size of the, and various one or more interdependencies of multiple maintenance or updates processes.

12. The non-transitory computer readable medium (107, 127) of any one of claims 1-11, wherein the medical device (120) comprises a fleet of medical devices, and the wherein the instructions are readable and executable by the at least one hardware processor (101, 113) to further: coordinate the upcoming maintenance or update session for the medical devices in the fleet; and wherein the coordinating includes automatically performing a software update of the upcoming maintenance or update session for the medical devices in the fleet in accordance with the coordination.

13. The non-transitory computer readable medium (107, 127) of claim 12, wherein the instructions are readable and executable by the at least one hardware processor (101, 113) to further: identify third party software (134) loaded on each medical device (120) in the fleet of medical devices which is not included in the set of vendor-supplied software (132) loaded on the medical device; receive an input from a customer of an indication of an acceptance of the upcomingmaintenance or update session of the of vendor-supplied software; and coordinate the upcoming maintenance or update session of the vendor-supplied software (132) with updates to the identified third-party software.

14. The non-transitory computer readable medium (107, 127) of any one of claims 1-13, wherein the instructions are further readable and executable by at least one hardware processor (101, 113) to: automatically scan the medical device (120) and / or automatically analyze a software bill of materials (128) of the medical device to identify third party software (134) loaded on the medical device which is not compatible with a software update of the upcoming maintenance or update session; output (208), on the UI (140, 144), instructions to perform an update to the identified third-party software prior to the determined proposed time; and at the determined proposed time, automatically perform the software update of the upcoming maintenance or update session.

15. A non-transitory computer readable medium (107, 127) storing instructions readable and executable by at least one hardware processor (101, 113) to perform an update method (200) for a set of vendor-supplied software (132) loaded on a medical device (120), the update method comprising: automatically scanning the medical device and / or automatically analyzing a software bill of materials (128) of the medical device to identify third party software (134) loaded on the medical device which is not included in the set of vendor-supplied software loaded on the medical device; automatically comparing the identified third-party software with software dependency data (129) to identify at least one dependency between the identified third-party software and the set of vendor-supplied software loaded on the medical device; performing a remedial action in response to determining, based on the identified at least one dependency, that the identified third-party software is incompatible with an update to the set of vendor-supplied software loaded on the medical device; and after performing the remedial action, performing the update to the set of vendor-supplied software loaded on the medical device.

16. The non-transitory computer readable medium (107, 127) of claim 15, wherein the performing of the remedial action includes one of: automatically updating the identified third-party software prior to performing the update to the set of vendor-supplied software loaded on the medical device; or outputting (208) a request to update the identified third-party software prior to performing the update to the set of vendor-supplied software loaded on the medical device.

17. The non-transitory computer readable medium (107, 127) of any one of claims 15-16, wherein the update method (200) further includes: determining a proposed time for performing the upcoming maintenance or update session comprising the remedial action; and outputting, on a user interface (UI) (140, 144), at least an indication of the determined proposed time.

18. The non-transitory computer readable medium (107, 127) of claim 17, wherein the UI (140, 146) comprises a UI (140) displayed on an electronic processing device (102) operable by a vendor of the medical device (120), the UI including one or more proposed time windows for performing the upcoming maintenance or update session.

19. The non-transitory computer readable medium (107, 127) of either one of claims 17 and 18, wherein the UI (140, 146) comprises a UI (146) displayed on an electronic processing device (144) operable by a customer of the medical device (120), the UI including one or more proposed time windows selectable by the customer to schedule the upcoming maintenance or update session.

20. An update method (200) for a set of vendor-supplied software (132) loaded on a medical device (120), the update method comprising: receiving one or more inputs related to an upcoming maintenance or update session for a medical device (120);analyzing the received one or more inputs to determine a proposed time for performing the upcoming maintenance or update session and / or third-party software loaded on the medical device that is incompatible with the upcoming maintenance or update session; outputting, on a user interface (UI) (146) displayed on an electronic processing device (144) operable by a customer of the medical device, the proposed time and / or instructions for updating the third-party software that is incompatible with the upcoming maintenance or update session.

Images