Tracking progress of active monitoring actions to avoid shutdown or performance degradation of medical devices

Abstract

Maintenance assistance is performed using a solution tree that includes leaf nodes corresponding to possible root causes of a maintenance problem, each leaf node including a probability and severity of a respective root cause. Data is received relating to a result of a completed service action performed for diagnosing the maintenance problem. The solution tree is updated with the received data, including updating the probability and severity of the root cause of the respective leaf node. One or more root causes to investigate are identified based at least on the update probabilities and update severity of the root causes for the respective leaf nodes. The one or more root causes to be investigated, as well as the update probability and update severity of the one or more corresponding root causes to be investigated, are displayed.

Description

Technical Field

[0001] The following generally relates to medical equipment maintenance techniques, medical imaging equipment maintenance techniques, medical equipment maintenance scheduling techniques, and related techniques. Background Art

[0002] To proactively avoid unplanned downtime, medical imaging systems (such as magnetic resonance imaging (MRI) systems, computed tomography (CT) systems, positron emission tomography (PET) systems, interventional radiology (IR) systems, X-ray and image-guided therapy (IGT) systems, or other medical imaging systems), as well as picture archiving and communication systems (PACS) are remotely monitored. These systems generate log messages (or alerts) that can be displayed on a dashboard, and remote monitoring engineers use these log messages to identify problems before they cause downtime or performance degradation. In addition, remote monitoring engineers can react to alerts generated by predictive models using multiple log messages, which may require additional priority and time constraints.

[0003] For example, a log message could indicate that an X-ray tube filament is nearing the end of its life, and a new X-ray tube could be ordered so that the tube can be replaced quickly if the filament breaks, or proactively before the filament breaks. Similarly, a high central processing unit (CPU) load on a specific part of the PACS could indicate that some software component has accidentally developed a memory leak, resulting in excessive memory and CPU usage, and remotely restarting these components could avoid subsequent downtime or performance degradation.

[0004] In some cases, remote monitoring can be fully automated. In these cases, the log messages provide enough information to determine the exact root cause of the problem. In these cases, the problem and its correct root cause can be derived from the specific pattern of the log messages. In other cases, determining the correct root cause may be difficult or even impossible to automate. This may be because additional checks need to be performed to determine the correct root cause. Some of these checks may only be performed when a person is logged in remotely. It may not be feasible or desirable to fully automate these steps. Developing an automated process for a complete solution tree may be considered too costly, especially if it involves problems that rarely occur. In addition, the hospital using the system may not desire the required automated remote logins for security reasons. In addition, additional checks may interfere with the normal functioning of such a system and therefore can only be performed when no patients are being examined. This requires coordination between the remote monitoring engineer and the hospital system operators to determine the appropriate time to perform additional checks.

[0005] In the latter case, problem solving can be a complex process, with these problems identified automatically by recognizing suspicious patterns in log messages or by remote monitoring engineers based on their own experience. At the same moment, there may be multiple issues that need to be addressed, and each of them may require remote logging at different times that are suitable for the respective hospital. As a result, some identified issues may be overlooked when they are awaiting further analysis, resulting in unnecessary downtime or performance degradation.

[0006] Certain improvements that overcome these and other problems are disclosed below. Summary of the invention

[0007] In one aspect, a non-transitory computer-readable medium stores a solution tree including data related to a solution to a maintenance problem of a medical imaging device. The solution tree includes leaf nodes corresponding to possible root causes of the maintenance problem. Each leaf node includes the probability of a corresponding root cause and the severity of the corresponding root cause. The non-transitory computer-readable medium also stores instructions that can be read and executed by at least one electronic processor to perform the following operations: receiving data related to the results of a completed service action performed to diagnose the maintenance problem; updating the solution tree with the received data, including updating the probability of the root cause of the corresponding leaf node; identifying one or more root causes to be investigated based at least on the updated probability of the root cause of the corresponding leaf node; displaying one or more root causes to be investigated and the updated probability of the corresponding one or more root causes to be investigated on a display device of a remote electronic processing device that can be operated by a service engineer (SE); and repeating the receiving, updating and displaying operations for each successive completed service action to update the displayed probability of one or more possible root causes to be investigated and one or more corresponding root causes to be investigated. In some embodiments, the one or more root causes to be investigated are further identified based on the severity of the corresponding root cause. In some embodiments, the displaying operation further displays a severity of one or more corresponding root causes to be investigated.

[0008] In some embodiments described in the preceding paragraph, updating the solution tree with the received data includes: calculating an updated severity value based on historical data of historical service actions that successfully resolved previous maintenance issues; and updating the solution tree with the calculated updated severity value. In some such embodiments, calculating the updated severity value includes: calculating the overall severity of the maintenance issue as the sum of the product of the calculated probability and severity value over all leaf nodes; and issuing an alert about the maintenance issue when the overall severity exceeds a threshold.

[0009] On the other hand, a non-transitory computer-readable medium stores a solution tree including data related to a solution to a maintenance problem of a medical imaging device. The solution tree includes leaf nodes corresponding to possible root causes of the maintenance problem. Each leaf node includes the probability of the corresponding root cause and the severity of the corresponding root cause. The non-transitory computer-readable medium also stores instructions that can be read and executed by at least one electronic processor to perform the following operations: receiving data related to the results of a completed service action performed to diagnose a maintenance problem; updating the solution tree with the received data, including updating the probability of the root cause of the corresponding leaf node; identifying one or more root causes to be investigated based at least on the updated probability of the root cause of the corresponding leaf node; displaying one or more root causes to be investigated and the updated probability of one or more corresponding root causes to be investigated on a display device of a remote electronic processing device that can be operated by an SE; receiving a schedule for a scheduled service action from a scheduler; and outputting a reminder to perform or schedule one or more service actions that are not scheduled service actions in the service action to be performed. In some embodiments, the one or more root causes to be investigated are further identified based on the severity of the corresponding root cause. In some embodiments, the operation of the display also displays the severity of one or more corresponding root causes to be investigated. In some embodiments, updating the solution tree with the received data includes: calculating an updated severity value based on historical data of historical service actions that successfully resolved previous maintenance issues; and updating the solution tree with the calculated updated severity value.

[0010] On the other hand, a method is disclosed, comprising: providing a solution tree, the solution tree including leaf nodes corresponding to possible root causes of a maintenance problem, wherein each leaf node includes a probability and a severity of a corresponding root cause; receiving data related to results of completed service actions performed to diagnose the maintenance problem; updating the solution tree with the received data, including updating the probability and severity of the root causes of the corresponding leaf nodes; identifying one or more root causes to be investigated based at least on the updated probability and updated severity of the root causes of the corresponding leaf nodes; and displaying the one or more root causes to be investigated and the updated probability and updated severity of the one or more corresponding root causes to be investigated on a display device.

[0011] One advantage resides in determining the correct root cause of a maintenance problem of a medical device.

[0012] Another advantage resides in minimizing the amount of time spent resolving medical device problems.

[0013] Another advantage resides in reducing security issues associated with data used to perform service actions on a medical device.

[0014] Another advantage is that the amount of time spent resolving medical device issues is minimized by distributing the task among multiple remote monitoring engineers.

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

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

[0017] Figure 1 An illustrative system for determining a root cause and at least one recommended service action for repairing a medical device in accordance with the present disclosure is schematically shown.

[0018] Figure 2 Shows Figure 1 An exemplary flow chart operation of a system. DETAILED DESCRIPTION

[0019] In medical imaging services, remote service engineers (RSEs; or proactive monitoring engineers, etc.) handle pending issues manually or through predictive algorithms. However, resolving pending issues may involve multiple steps, some of which are time-constrained by factors such as the need to log into the imaging system when the imaging system is not being used for patient imaging. As a result, issues may be forgotten and remain unresolved until they manifest themselves as equipment failures or other harmful means.

[0020] The following discloses an intelligent work order system for problems. The system defines problems as observation patterns, such as A∧B∧NOT(C), where A, B, and C can be log messages. Each problem defined in this way is associated with a solution tree, which is usually constructed by experts and includes a root node corresponding to the problem, intermediate nodes representing service actions performed to solve the problem, and leaf nodes corresponding to possible diagnosed root causes. Each leaf node has an associated probability of a root cause and the severity of the root cause.

[0021] When an RSE enters a problem into the system, the system monitors the results of the service actions performed to diagnose the problem and based on these results dynamically updates the probabilities of various root causes when certain leaves are unreachable. Service actions that have been scheduled but not yet performed are also recorded.

[0022] The system can also calculate the severity value of the root cause corresponding to the leaf node based on historical data, and as the historical data continues to accumulate, this update can also optionally dynamically update the calculated severity of the root cause corresponding to the leaf node. In addition, the system calculates the overall probability and / or severity of each problem as the sum of the product of probability and severity over all leaf nodes of the associated solution tree.

[0023] The system also provides a user interface (UI) to enable the RSE to access this information. In some examples, a two-level UI may be provided. The first level is an overview screen that lists all open issues with information such as overall severity and the top K most likely root causes. The second level is reached by clicking on a specific issue, which brings up additional information for that issue.

[0024] In some embodiments, the disclosed system provides time-based reminders of pending issues. This feature takes into account scheduled service actions, so that, for example, if the next service action has already been scheduled, the RSE will not receive a reminder.

[0025] refer to Figure 1 , schematically shows an illustrative service support system 100 for supporting service engineers in repairing equipment 120 (e.g., medical imaging devices - also referred to as medical devices, imaging devices, imaging scanners, and variations thereof). As some non-limiting illustrative examples, the medical imaging devices in service may be magnetic resonance imaging (MRI) scanners, computed tomography (CT) scanners, positron emission tomography (PET) scanners, gamma cameras for performing single photon emission computed tomography (SPECT), interventional radiology (IR) equipment, and the like. (More generally, the disclosed method may be applied in conjunction with any type of computerized device that automatically generates log data that is analyzed by a predictive model to predict component failures, e.g., the method may be applied to commercial airliners, radiation therapy equipment, and the like). As Figure 1As shown, the service support system 100 includes a service device 102 or can be accessed by the service device 102, which can be, for example, a workstation or electronic processing device used by the RSE. The service device 102 can be a desktop computer or a personal device, such as a mobile computer system (such as a laptop or smart device). In other embodiments, the service device 102 can be an imaging system controller or computer integrated or operably connected to the imaging device being serviced (for example, at a medical institution). As another example, the service device 102 can be a portable computer (for example, a laptop, a tablet computer, etc.) carried by the RSE, which performs fault diagnosis and parts ordering of the imaging device. In another example, the service device 102 can be a controller computer of the imaging device in service, or a computer of the hospital. In other embodiments, the service device can be a mobile device such as a cellular phone (mobile phone) or a tablet computer.

[0026] The service device 102 includes a display 105 via which alarms generated by the predictive fault model are displayed, as well as possible root causes and service action recommendation information as disclosed herein. The service device 102 also preferably allows a service engineer to interact with the service support system via at least one user input device 103 (such as a mouse, keyboard, or touch screen). The service device also includes an electronic processor 101 and a non-transitory storage medium 107 (in Figure 1 100). The non-transitory storage medium 107 stores instructions that can be read and executed by the electronic processor 101 for interfacing with the service support system 100. The service device 102 also includes a communication interface 109 for communicating with a back-end server or processing device 111, which typically implements the computing aspects of the service support system 100 (e.g., the server 111 has processing capabilities for implementing the computationally complex aspects of the service support system 100). Such communication interfaces 109 include, for example, wired and / or wireless Ethernet interfaces (e.g., in the case where the service device 102 is an RSE workstation); or in the case where the service device 102 is a portable FSE device, the interface 109 can be a wireless Wi-Fi or 4G / 5G interface for connecting to the Internet and / or an intranet, etc. Some aspects of the service support system 100 can also be implemented through cloud processing or other remote processing (i.e., the server computer 111 can be embodied as a cloud-based computing resource including multiple interconnected servers).

[0027] in exemplary Figure 1In the embodiment, the service support system also includes a back end 110 (e.g., implemented and / or owned by the imaging device vendor, or leased by the vendor from a cloud computing service provider). The back end 110 continuously or occasionally receives log data (e.g., machine logs automatically generated by the medical imaging device 120, service logs of the medical imaging device 120, etc.) (e.g., in some settings, the imaging device 120 uploads machine log entries to the back end 110 every day). The back end can optionally perform processing for performing predictive fault modeling, in which case the problem can be automatically pending (e.g., if fault modeling predicts that the X-ray tube may fail in the next month, a service work order can be automatically generated to replace the X-ray tube). The back end can optionally additionally or alternatively provide a work order system, etc., through which a user can manually open a work order for pending issues.

[0028] The backend also performs maintenance service analytics on a backend server 111, which is equipped with an electronic processor 113 (schematically indicated as an internal component). These analytics provide automatic tracking of the handling of issues pending automatically or manually. The server 111 is equipped with a non-transitory storage medium 127 (in Figure 1 Although a single server computer is shown, it should be understood that the back end 110 may be more generally implemented on a single server computer, or a server cluster, or a cloud computing resource including server computers interconnected in an ad hoc manner, etc. Figure 1 A single medical imaging device 120 is shown, but more generally, the database backend 110 will receive log data from many medical imaging devices (eg, tens, hundreds, or more imaging devices) and perform the disclosed processes for each such medical imaging device.

[0029] Continue to refer Figure 1 The non-transitory computer readable medium 127 stores a solution tree 130 associated with a solution to a maintenance problem of the medical imaging device 120. Figure 1 As shown, Figure 1A rendering of a solution tree 130 is presented, the solution tree 130 including leaf nodes 132 (depicted as circles) and edges 134 (depicted as arrows) connecting the nodes. The solution tree 130 contains data related to a maintenance problem of a medical imaging device 120, and the nodes 132 correspond to possible root causes of the maintenance problem. Each leaf node 132 includes a probability of a corresponding root cause. In some embodiments, each leaf node 132 also includes a severity of the corresponding root cause. The severity of the corresponding root cause can be calculated based on various metrics, such as cost in monetary units, cost of downtime, performance of the medical imaging device, and / or cost measured by another selected severity metric. In one example, the severity of the root cause represents the impact of the root cause on the performance of the medical imaging device, such as due to reduced image quality and / or the inability to perform certain types of imaging and / or diagnostic clinical tasks due to the root cause. In another example, the severity of the root cause represents the downtime of the medical imaging device caused by the root cause. In another example, the severity of the root cause represents a summary of the impact on the performance of the medical imaging device and the downtime of the medical imaging device caused by the root cause. In another example, the severity of the root cause represents the monetary cost of resolving the root cause. In some embodiments, the solution tree 130 also includes a root node 131 corresponding to the maintenance problem, and a plurality of intermediate nodes 133, each intermediate node 133 representing a service action that can be performed to attempt to resolve the maintenance problem. Although a single illustrative solution tree 130 is shown by way of illustrative example, multiple solution trees may be stored, each of which is constructed for a particular problem or a particular class, type, or category of problems.

[0030] The non-transitory storage medium 127 also stores instructions executable by the electronic processor 113 of the backend server 111 to perform the method 200 of assigning tasks to different RSEs for a current service case of maintaining the medical imaging device 120 .

[0031] Continue to refer Figure 1 And further reference Figure 2 , schematically shows, in flowchart form, an illustrative embodiment of a method 200 that may be performed by electronic processor 113. In some examples, method 200 may be performed at least in part by cloud processing.

[0032] To begin method 200, at operation 202, data 136 related to the results of completed service actions performed to diagnose a maintenance problem is received from a customer of medical device 120, such as by backend server 111 (operable by a vendor). (It is assumed here that the completed service action is resolving an existing pending problem).

[0033] At operation 204, the solution tree 130 is updated with the received data, including updating the probability of the root cause of the corresponding leaf node 132. In some embodiments, the updating operation 204 also includes calculating or updating the severity value based on the historical data of the historical service actions that successfully resolved the previous maintenance issues, and updating the solution tree 130 with the calculated severity value. For example, calculating or updating the severity value includes calculating the overall severity of the maintenance issue as the product of the calculated probability and the severity value summed over all leaf nodes 132, and issuing an alert on the service device 102 regarding the maintenance issue when the overall severity exceeds a threshold. As an example of such an update, consider a solution tree 130 with three leaf nodes A, B, and C, where leaf node A is labeled with a probability P A = 0.50 and severity 1, leaf node B is marked with probability P B = 0.30 and severity 2, leaf node C is marked with probability P C = 0.20 and severity 3. If the completed service action has eliminated leaf node C (eg, the result produced by the completed service action eliminates the root cause associated with leaf node C), then set P C = 0, and the probability P of the corresponding remaining leaf nodes A and B can be adjusted accordingly A and P B , e.g. by distributing the (now eliminated) probability P between the remaining nodes A and B proportionally C = 0.20. For example, this can be done by setting and To achieve this, P A +P B +P C =0.625+0.375+0=1.000 still holds true.

[0034] At operation 206, one or more root causes to be investigated are identified based at least on the updated probabilities of the root causes of the corresponding leaf nodes 132. In the previous example, of the two remaining leaf nodes A and B, node A has the highest probability (adjusted P A=0.625), so this tends to investigate the possibility of the root node associated with node A next. In some examples, one or more root causes to be investigated are further identified based on the severity of the corresponding root causes. In the ongoing example, this will tend to investigate the root cause of node B next, because the severity 2 of node B is higher than the severity 1 of node A (here it is assumed that the higher value is a higher severity, that is, the cost expressed in monetary units, downtime, or another selected severity metric is higher). In some embodiments, a weighted priority can be adopted, for example, the next leaf node / root cause to be investigated is selected based on a weighted combination of probability and severity. In some embodiments, one or more service actions to be performed can be identified based on one or more root causes to be investigated and the intermediate node 133. To this end, the back-end server is configured to receive a schedule 138 for scheduled service actions from the scheduler, and output a reminder on the service device 102 to execute or schedule one or more service actions in the service action to be performed that are not scheduled service actions.

[0035] At operation 208, one or more root causes to be investigated and the updated probability of the one or more corresponding root causes to be investigated (and optionally the severity of the one or more corresponding root causes to be investigated) are displayed on the display device 105 of the service device 102. To this end, a first user interface (UI) 140 can be provided on the display device 105, and the first user interface (UI) 140 is configured to display the calculated overall severity of the maintenance issue. A second UI 142 can also be provided on the display device 105 and is configured to display information related to a specific root cause of the maintenance issue. In some examples, the second UI 142 can be displayed when a user input indicating a selection of a portion of the first UI 140 is received via at least one user input device 103.

[0036] In some embodiments, the receiving operation 202, the updating operation 204, and the displaying operation 208 may be repeated for each successive completed service action (eg, Figure 2 ), to update the displayed one or more possible root causes to be investigated and the probability of one or more corresponding root causes to be investigated.

[0037] In some embodiments, the solution tree 103 and / or one or more root causes to be investigated and the updated probabilities of the corresponding one or more root causes to be investigated (and optionally the severity of the one or more corresponding root causes to be investigated) are displayed on a customer UI 144 displayed on a customer electronic processing device 146 operable by the customer.

[0038] Example

[0039] The service support system 100 is configured to automatically track the active monitoring process performed by the remote monitoring engineer. This involves estimating the severity of each identified issue and monitoring whether sufficient progress is being made in resolving open issues taking into account their estimated severity. If insufficient progress is detected, particularly for issues that are assumed to have high severity, a dedicated alert is generated that draws the attention of the remote service engineer to these issues. In addition, the proposed monitoring can help the remote monitoring engineer determine which issues should be considered next for further resolution. The order in which the issues are handled next will be iteratively adjusted whenever there is new information about the probability and severity of possible root causes that are still outstanding.

[0040] Let the problem be specified by a logical pattern of occurrence of different types of log messages, which may involve additional priority and timing conditions on these log messages. For example, a logical pattern could be the occurrence of log messages A and B, where A must be observed before B, and where the time between the observations of A and B must not exceed 5 minutes, while in the interval between the observations of A and B, no third log message C appears. Such a pattern can be described as A∧B∧NOT(C), with additional priority and timing conditions. Alternatively, the problem can be specified by the fact that a given parameter being monitored exceeds a certain threshold. For example, the number of files residing in a given wait queue exceeds a given threshold. Or, alternatively, the CPU usage of a given process exceeds a certain threshold when measured in elapsed time units, where the time unit is an appropriately chosen measure of time, such as 5 minutes or 1 hour.

[0041] For each problem i, the solution tree T i Solution Tree T i = (V, E) is a node with a root node r and multiple leaf nodes l i，1 , l i，2 , ..., l i，n(i) where n(i) represents the number of different root causes that can be associated with problem i. i All edges in the root node r point to leaf nodes. Each leaf node l i，j corresponds to having an associated probability p(l i，j ), severity s(l i，j ) and the specific root causes of i，j A sequence of service actions to solve the problem given the root cause. i，j ). Intermediate nodes are considered to be checks that must be performed by remote monitoring engineers, and may require remote login to the system in risky situations, and may require appointments to perform remote logins at times when the system is not in use.

[0042] Let leaf node l i，jThe severity of the associated root cause i，j ) is given by a real number in [0, 1], where values ​​close to 0 indicate low severity and values ​​close to 1 indicate high severity. High severity indicates that the system will experience downtime if the problem is not handled properly. In addition, the probability p(l i，j ) The root cause of problem i is related to leaf node l i，j The estimated probability of the associated root cause, such that 0 ≤ p(l i，j )≤1 for all j∈{1, 2, ..., n(i)} and according to equation (1):

[0043]

[0044] Initially, if no additional checks have been performed on solving problem i, the severity s(i) of problem i can be estimated by the weighted average of the severity of all its leaf nodes. For example, equation (2) represents:

[0045]

[0046] After additional inspection, some leaf nodes are no longer accessible after new information becomes available. Updating the severity of the problem can be achieved by setting the probabilities of these leaf nodes to zero and increasing the probabilities of other leaf nodes proportionally so that the sum of their probabilities adds up to 1 again. Alternatively, the new information may change the relative probabilities of the remaining root causes, resulting in another adjustment of the probabilities of the remaining root causes so that they add up to 1 again. The estimates of probability and severity are based on data from historical problems, as long as these data are applicable to the given information of the specified problem. The more information available about previous similar problems, the more accurate these estimates are. Initially, if no information is available, all potential root causes are considered equally likely and equally severe. And, as more data about historical problems is collected, these a priori probabilities are adjusted accordingly.

[0047] The definition of severity for each issue can be used to rank the issues to determine which issue should be considered next and thus advance its resolution. In other words, the estimated severity can be used to provide recommendations to the service engineer about which issue to work on next. For such recommendations, it is also possible to take into account appointments that have already been made for a remote login. For example, if an appointment for a remote login is scheduled within the next 10 minutes, then the recommendation can take this into account, if this will take longer than the available time before the appointment, then it is not recommended to consider taking the next action for the open issue. However, in the first place, tracking the changing estimated severity is intended to be used to track the progress of resolving various issues.

[0048] For example, the resolution progress of open issues should be captured in the UI that service engineers use to enter service actions taken. Service engineers record which service actions have been performed for each issue. Issues will be identified by case or ticket number, and the type of warning or error log message or alert with associated data will allow the monitoring application to determine the type of issue at hand and identify the corresponding solution tree with associated additional checks (represented by intermediate nodes) and root causes (represented by leaf nodes).

[0049] Assume that the UI consists of a main window showing an ordered list of pending issues, which can be sorted according to different criteria given in Table 1.

[0050]

[0051]

[0052] Table 1

[0053] Table 1 shows the main window of the UI, which shows a list of pending issues sorted in descending order of severity. The third column gives the status of the pending issue, for example showing how long the issue has been pending if a remote login requires an appointment, and whether the next action has been planned. The fourth, fifth, and sixth columns give detailed information about the three most likely root causes for each pending issue. These details include the severity and probability of the root cause, as well as other possible details, such as the effort required to determine whether this is the actual root cause.

[0054] By clicking on an open issue in the main window, more detailed information is shown in the next window dedicated to the specific open issue, showing a longer list of possible root causes and further details on how to further handle the open issue. This second window gives further details on how long the issue has been open and the actions that have been performed to resolve the issue, an overview of the actions that can be performed, split into actions that do not require remote login and actions that do require remote login. In addition, an estimated duration for each action is given. If appropriate, an appointment for remote login is also shown at a time suitable for the hospital. This is shown in Table 2.

[0055] Unresolved issues History of open issues, including a list of actions performed Possible appointments for remote login Details about the root cause l_i,1 Details about the root cause l_i,2 Details about the root cause l_i,3 More information about the root cause...

[0056] Table 2

[0057] Table 2 shows an example of a new window showing the history of the open issue for a selected open issue, including the time the issue was raised and the history of actions that have been performed to resolve the issue. The window also includes possible appointments that have been made with the hospital to perform the next action requiring remote login at a time convenient for the hospital. In addition, the window gives details of the full list of root causes that still have a positive probability, given the actions that have been performed.

[0058] By automatically tracking the progress of each open issue, alerts can be automatically generated when no progress has been made on an issue within a given time interval. These alerts can be set relative to the moment the issue was raised, or the alert can be set relative to the last moment when any progress was made on a given issue. In addition, the estimated severity s(i) of issue i, as defined by one of the above alternatives, can be used to determine whether such an alert should be issued. An alert can be generated whenever the weighted sum of the elapsed time and the severity reaches a certain threshold. Alternatively, the size of the duration (relative to the moment the issue was detected or relative to the last progress) can be selected based on the estimated severity s(i) of the issue.

[0059] Alternatively, a service engineer can set a timer to generate an alert whenever a given parameter exceeds a manually selected threshold. For example, if the number of files in a given input queue triggers an alert, a possible action for the resulting pending issue could be to temporarily set a new higher threshold so that whenever that higher threshold is exceeded, a higher priority alert is raised. Based on their personal experience, a service engineer might want to see if the queue is just experiencing a temporary high load that can be resolved in a short period of time without human intervention.

[0060] Tracking of active monitoring teams makes it easier to assist third-party service providers without revealing too much knowledge about how to resolve these issues. Third-party service providers will not get the details of the solution tree and the estimated severity and probability. They will only get recommendations on what to do next. Given the diversity of issues that may be pending at the same time, it is difficult for them to extract useful value from these severities and probabilities from these recommendations.

[0061] The service support system 100 is applicable to various types of medical equipment where remote logging is important to determine the root cause of a possible problem. Considering patient safety, remote logging may not always be desirable at any time. This includes medical imaging systems and PACS. In addition, the service support system 100 can be applicable to other application areas where unplanned downtime should be avoided and performing additional inspections may interfere with normal business operations.

[0062] Non-transitory storage media include any media for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, machine-readable media include read-only memory ("ROM"), solid-state drives (SSD), flash memory, or other electronic storage media; hard drives, RAID arrays, or other disk storage media; optical disks or other optical storage media; and the like.

[0063] The methods shown in this specification may be implemented as instructions stored on a non-transitory storage medium and read and executed by a computer or other electronic processor.

[0064] The present disclosure has been described with reference to preferred embodiments. Modifications and alterations may occur to others after reading and understanding the above detailed description. It is intended that the exemplary embodiments be interpreted as including all such modifications and alterations as long as they fall within the scope of the claims or their equivalents.

Claims

1. A non-transitory computer-readable medium (107, 127) storing: A solution tree (130) comprising data related to a solution to a maintenance problem of a medical imaging device (120), the solution tree comprising leaf nodes (132) corresponding to possible root causes of the maintenance problem, wherein: Each leaf node includes the probability of the corresponding root cause and the severity of the corresponding root cause; as well as Instructions readable and executable by at least one electronic processor (101, 113) to: receiving data related to results of completed service actions performed to diagnose the maintenance problem; updating the solution tree with the received data, including updating the probability of the root cause of the corresponding leaf node; identifying one or more root causes to investigate based at least on the updated probabilities of the root causes for the corresponding leaf nodes; displaying the one or more root causes to be investigated and the updated probabilities of the one or more corresponding root causes to be investigated on a display device (105) of a remote electronic processing device (102) operable by a service engineer (SE); and The receiving, updating, and displaying operations are repeated for each successive completed service action to update the displayed one or more possible root causes to be investigated and the probability of the one or more corresponding root causes to be investigated.

2. The non-transitory computer readable medium (107, 127) of claim 1, wherein: The one or more root causes to investigate are further identified based on the severity of the respective root causes.

3. The non-transitory computer readable medium (107, 127) of claim 1, wherein: The displaying operation also displays the severity of the one or more corresponding root causes to be investigated.

4. The non-transitory computer readable medium (107, 127) of claim 1 or 2, wherein: The solution tree (130) also includes: The root node (131) corresponding to the maintenance problem, and A plurality of intermediate nodes (133), each intermediate node representing a service action that can be executed to attempt to resolve the maintenance problem.

5. The non-transitory computer readable medium (107, 127) of claim 4, wherein: The instructions also identify one or more service actions to be performed based on the one or more root causes to be investigated and the intermediate node (133).

6. The non-transitory computer readable medium (107, 127) of claim 5, wherein: The instructions also include: receiving a schedule for a scheduled service action from a scheduler (138); and A reminder is output to perform or schedule one or more of the service actions to be performed that are not scheduled service actions.

7. The non-transitory computer readable medium (107, 127) according to any one of claims 2-6, wherein: Updating the solution tree (130) with the received data includes: Calculating an update severity value based on historical data of historical service actions that successfully resolved previous maintenance issues; and The solution tree is updated with the calculated updated severity value.

8. The non-transitory computer readable medium (107, 127) of claim 7, wherein: Calculating the update severity value includes: Calculating the overall severity of the maintenance issue as the sum of the products of the calculated probability and severity values ​​over all leaf nodes (132); and An alert is issued regarding the maintenance issue when the overall severity exceeds a threshold.

9. The non-transitory computer readable medium (107, 127) according to any one of claims 7 and 8, wherein: The display device (105) is configured to display a first UI (140) configured to display the calculated overall severity of the maintenance issue.

10. The non-transitory computer readable medium (107, 127) according to any one of claims 8 and 9, wherein: The display device (105) is configured to display a second UI (142) configured to display information related to a specific root cause of the maintenance issue.

11. The non-transitory computer readable medium (107, 127) of claim 10, wherein: The instructions also include: The second UI (142) is displayed upon receiving a user input indicating a selection of a portion of the first UI (140).

12. A non-transitory computer-readable medium (107, 127) storing: A solution tree (130) comprising data related to a solution to a maintenance problem of a medical imaging device (120), the solution tree comprising leaf nodes (132) corresponding to possible root causes of the maintenance problem, wherein: Each leaf node includes the probability of the corresponding root cause and the severity of the corresponding root cause; as well as Instructions readable and executable by at least one electronic processor (101, 113) to: receiving data related to results of completed service actions performed to diagnose the maintenance problem; updating the solution tree with the received data, including updating the probability of the root cause of the corresponding leaf node; identifying one or more root causes to investigate based at least on the updated probabilities of the root causes for the corresponding leaf nodes; displaying the one or more root causes to be investigated and the updated probabilities of the one or more corresponding root causes to be investigated on a display device (105) of a remote electronic processing device (102) operable by a service engineer (SE); receiving a schedule for a scheduled service action from a scheduler (138); and A reminder is output to perform or schedule one or more of the service actions to be performed that are not scheduled service actions.

13. The non-transitory computer readable medium (107, 127) of claim 12, wherein: The one or more root causes to investigate are further identified based on the severity of the respective root causes.

14. The non-transitory computer readable medium (107, 127) of claim 12, wherein: The displaying operation also displays the severity of the one or more corresponding root causes to be investigated.

15. The non-transitory computer readable medium (107, 127) of claim 12 or 13, wherein: The solution tree (130) also includes: The root node (131) corresponding to the maintenance problem, and A plurality of intermediate nodes (133), each intermediate node representing a service action that can be executed to attempt to resolve the maintenance problem.

16. The non-transitory computer readable medium (107, 127) of claim 15, wherein: The instructions also identify one or more service actions to be performed based on the one or more root causes to be investigated and the intermediate node (133).

17. The non-transitory computer readable medium (107, 127) of claim 16, wherein: The instructions also include: The receiving, updating, and displaying operations are repeated for each successive completed service action to update the displayed one or more possible root causes to be investigated and the probability of the one or more corresponding root causes to be investigated.

18. The non-transitory computer readable medium (107, 127) according to any one of claims 13-17, wherein: Updating the solution tree (130) with the received data includes: Calculating an update severity value based on historical data of historical service actions that successfully resolved previous maintenance issues; and The solution tree is updated with the calculated updated severity value.

19. The non-transitory computer readable medium (107, 127) of claim 18, wherein: Calculating the update severity value includes: Calculating the overall severity of the maintenance issue as the sum of the products of the calculated probability and severity values ​​over all leaf nodes (132); and An alert is issued regarding the maintenance issue when the overall severity exceeds a threshold.

20. A method (200), comprising: providing a solution tree including leaf nodes (132) corresponding to possible root causes of the maintenance problem, wherein each leaf node includes a probability and a severity of the corresponding root cause; receiving data related to results of completed service actions performed to diagnose the maintenance problem; Updating the solution tree (130) with the received data, including updating the probability and severity of the root cause of the corresponding leaf node; identifying one or more root causes to investigate based at least on the updated probabilities and updated severities of the root causes for the corresponding leaf nodes; and The one or more root causes to be investigated and the updated probabilities and updated severities of the one or more corresponding root causes to be investigated are displayed on a display device (105).

Images