Systems and methods for implementing predictive maintenance of interconnect communication issues in a test chamber

Abstract

A predictive maintenance method includes retrieving log data (30) of events of a plurality of medical devices (12) generated during a medical procedure employing the plurality of medical devices; comparing portions of the log data of two or more of the plurality of medical devices to a context representing expected interconnection communications between the two or more medical devices during the medical procedure; based on the comparison, detecting one or more interconnection communication errors between the two or more of the plurality of medical devices; and outputting an alert (36) identifying the one or more interconnection communication errors.

Description

Technical Field

[0001] The following generally covers the fields of equipment and system monitoring, medical device maintenance, predictive maintenance, device-to-device communication, image-guided therapy (IGT) kit maintenance, and related fields. Background Technology

[0002] Modern medical systems, such as IGT kits, contain many interacting electronic components, such as the X-ray system itself, associated treatment devices (e.g., excimer lasers and / or aspiration systems), and enhanced visualization devices (e.g., intravenous ultrasound (IVUS) and image rendering systems). Successful interventional treatment depends on the effective interaction between these systems.

[0003] A problem may occur in a given device, but such a problem may also manifest as a problem observed in another device. Typically, predictive maintenance diagnostics are performed on a device-by-device basis and are ineffective or fail to detect early problems in interactions between devices.

[0004] For example, image-guided therapy (IGT) systems typically include at least one imaging subsystem (e.g., a C-arm X-ray imaging gantry and patient table and / or an intravascular ultrasound (IVUS) system), a treatment-related subsystem (for performing intravascular catheter insertion and endovascular treatment procedures such as laser ablation, stent implantation, etc.), and a system for performing image-guided interventions (e.g., intravascular stent implantation, plaque resection, thrombectomy, etc.). Examples of such systems include the Philips Azurion. ® and Allura ® Interventional X-ray system series.

[0005] Auxiliary components work in conjunction with such IGT systems. For example, Spectranetics is included in some IGT kits offered by Royal Philips. ® Excimer lasers can be used to drive laser ablation catheters. Intrasight ® Intravascular ultrasound (IVUS) systems provide an additional imaging modality for intravascular invasive gastroscopy (IGT), and advanced visualization systems such as the Philips Interventional Workstation (IWS) can provide improved image rendering capabilities for X-ray systems. Other illustrative examples of systems that may be used in the context of IGT include automated aspiration systems.

[0006] The following are some improvements to overcome these and other issues. Summary of the Invention

[0007] In some embodiments disclosed herein, a non-transient computer-readable medium stores instructions that can be read and executed by an electronic processor to perform a predictive maintenance method. The predictive maintenance method includes: retrieving log data of events generated during a medical procedure employing multiple medical devices; comparing portions of the log data from two or more of the multiple medical devices with a context representing expected interconnect communication between the two or more medical devices during the medical procedure; based on the comparison, detecting one or more interconnect communication errors between the two or more medical devices; and outputting an alarm identifying the one or more interconnect communication errors.

[0008] In some embodiments disclosed herein, a non-transient computer-readable medium stores instructions that can be read, accessed, and executed by an electronic processor to perform a predictive maintenance method comprising: retrieving log data of events generated during a medical procedure employing multiple medical devices; applying one or more diagnostic rules to portions of the log data of two or more of the multiple medical devices using a context representing anticipated interconnect communication between the two or more medical devices during the medical procedure; detecting one or more interconnect communication errors between the two or more medical devices based on the comparison; and outputting an alarm identifying the one or more interconnect communication errors.

[0009] In some embodiments disclosed herein, a predictive maintenance method includes: retrieving log data of events from multiple medical devices generated during a medical process employing multiple medical devices; identifying timestamped events in the log data of the two or more medical devices that correspond to events with known time synchronization during the medical process; adjusting the timestamps of the log data of at least one of the two or more medical devices based on a comparison of the timestamps of the timestamped events with the known time synchronization; comparing portions of the log data of the two or more medical devices with a context representing expected interconnect communication between the two or more medical devices during the medical process; detecting one or more interconnect communication errors between the two or more medical devices based on the comparison; and outputting an alert identifying the one or more interconnect communication errors.

[0010] One advantage is that it generates predictive maintenance models for multiple medical devices based on the interconnected communication between them.

[0011] Another advantage is the reduction of false alarms between medical devices in multiple medical devices.

[0012] Another advantage lies in identifying interconnection and communication issues between multiple medical devices.

[0013] Another advantage is the application of machine learning (ML) models to identify the root causes of communication problems between multiple medical devices.

[0014] The given embodiments may not provide the aforementioned advantages, may provide one, two, more or all of the aforementioned advantages, and / or may provide other advantages, as will become apparent to those skilled in the art upon reading and understanding this disclosure. Attached Figure Description

[0015] This disclosure may take the form of various components and their arrangements, as well as various steps and their arrangements. The accompanying drawings are for illustrative purposes only and should not be construed as limiting this disclosure.

[0016] Figure 1 A predictive maintenance device according to the present disclosure is illustrated schematically.

[0017] Figure 2 The illustration shows the use Figure 1 Alarm monitoring methods for devices. Detailed Implementation

[0018] The following discloses a method for providing interoperability diagnostics between medical devices. This method utilizes log data files generated by various devices. While described herein primarily with reference to the IGT suite, the disclosed method can be applied to other types of imaging suites employing interconnected communication devices.

[0019] In some embodiments, log data from different devices in the IGT suite is synchronized in time, and can also be synchronized in other ways, such as to a common log data format.

[0020] To generate a diagnostic engine for detecting interconnect communication problems between devices in the IGT suite, historical log data is analyzed to identify normal event sequences during intervention procedures. Each event sequence consists of timestamped events logged on various devices. Prior knowledge of the expected intervention procedure workflow forms the basis of diagnostic rules for detecting anomalous event sequences that may trigger maintenance alerts. Event sequences can be anomalous in various ways, such as one or more device logs containing positive error messages, events that should occur simultaneously on different devices happening at different times, or successive events on different devices being delayed for excessively long periods, etc.

[0021] However, even during normal operation, the time intervals between events occurring on different devices can vary significantly depending on the instance of the intervention procedure. Synchronizing log data from different devices in time does not completely solve this problem, as the actual time of event recording may differ. Different operators may perform sequences of actions with time differences between them, or events such as the time it takes to ablate a lesion or the time it takes for an operator to accurately place a stent in a blood vessel may vary from procedure to procedure, resulting in normal variations in the time intervals between events. On the other hand, interconnection communication problems between devices can cause anomalous time differences. For example, communication bus problems can cause excessive delays between successive events on different devices, and it is these anomalous time differences that should trigger maintenance alerts.

[0022] Therefore, diagnostic rules are formulated in a parameterized manner, where time intervals and other possible aspects of the sequence are adjustable parameters. Machine learning (ML) or other analytical techniques then refine the parameters using historical service case data to generate tailored rules for the expected sequence of log events in the intervention process. These tailored rules can then effectively distinguish between anomalous time discrepancies that should trigger proactive maintenance (e.g., repairing the communication bus) and normal ranges of time discrepancies.

[0023] Some problems may be difficult to capture using rule-based diagnostic methods. For example, an error message generated by one device might actually be due to a problem with another device, or it might be caused by an interconnect communication issue. For instance, if the IGT system monitors laser power during the laser ablation procedure, an error indicating low (or no) laser power at the start of the procedure might not be a problem with the IGT system, but rather a problem with the excimer laser device, or a problem with the communication bus that delays the excimer laser device's startup. Furthermore, some error messages might be caused by operator error rather than maintenance issues. For example, an error message indicating the laser is not working might be due to the operator not turning on the laser.

[0024] Therefore, some diagnostic models can be implemented as machine learning (ML) models, such as artificial neural network (ANN) models. These models are appropriately trained on historical service cases to identify anomalous sequences of events with faults in specific devices or interconnect communication problems between specific devices. The input to these models is historical log data (or features derived from it) from logs of various devices in the IGT suite, labeled with maintenance problems identified by maintenance personnel in these historical cases. Some negative training samples may be provided as log data from various devices in the IGT suite collected during normal intervention procedures where no maintenance problems were identified.

[0025] During the inference phase, log data from the IGT kit devices is uploaded to the server computer and synchronized in terms of time and format. The synchronized log data is then fed into tuned diagnostic rules and trained ML diagnostic models to detect potential maintenance issues.

[0026] The disclosed system can be used to proactively detect issues, such as problems with a device within the IGT suite (which might manifest as error messages or warnings in the log data of another device), or interconnection communication problems between devices. In this application, identified problems are maintenance issues, and the output is appropriate maintenance alerts for service engineers.

[0027] In some embodiments, the diagnostic model is used to detect problems in the use of the equipment. For example, if log data from the IGT kit indicates that the operator frequently turns on the excimer laser at the wrong time during the intervention procedure, the model can generate an alert. In this case, the output can be sent to a radiology representative, for example, suggesting a review of training on excimer laser use, possibly accompanied by operating instructions (or relevant portions thereof).

[0028] While described primarily with reference to the IGT kit herein, the disclosed methods can be applied to other types of imaging kits employing interconnected communication devices. For example, positron emission tomography (PET), magnetic resonance imaging (MRI), and several other imaging modalities utilize intravascular contrast agent delivery in diagnostic imaging procedures, where the imaging sequence is closely synchronized with the timing of contrast agent inflow and outflow from the anatomical structure of interest. In MRI, a local coil can be used, employing wireless communication with the MRI scanner. Current diagnostic monitoring methods for ID can be readily applied to this situation, for example, to detect communication problems between the intravascular contrast agent injector device and the MRI scanner controller, or between the wireless local coil and the MRI scanner.

[0029] refer to Figure 1 An exemplary apparatus 10 for monitoring interconnect communication problems between multiple related medical devices or systems 12 is shown. Although described herein primarily with reference to IGT kits, the disclosed methods can be applied to other types of imaging kits employing interconnect communication devices. Medical device 12 may, for example, include: Medical imaging device 12 and / or its components. In the illustrative example, n=5 and the illustrative medical device 12 includes: a C-arm X-ray imager 12-1 for providing image guidance during catheter insertion into a blood vessel in an intravascular laser ablation treatment procedure; an excimer laser system 12-2; an ablation system 12-3 for performing laser ablation of a vascular occlusion using light from the laser system; an intravascular ultrasound imaging (IVUS) system 12-4 for providing imaging of the occlusion and its intravascular environment; and an image processing and presentation system 12-5 for processing, optionally fusing, and displaying images from the C-arm X-ray and IVUS systems. These devices are non-limiting exemplary typical devices constituting an image-guided therapy (IGT) suite for performing intravascular laser ablation to clear blood clots or other vascular occlusions. Although in Figure 1 Five imaging devices are shown: 12-1, 12-2, 12-3, 12-4, and 12-5, but any suitable number... Medical imaging device 12 may be included, and in some embodiments There can be 2, 3, 4, 5, 6, 8, 10, 12, dozens or more medical imaging devices, as a further non-limiting example. Figure 1 The diagram illustrates that devices 12-1, 12-2, 12-3, 12-4, and 12-5 communicate with each other via an electronic network 13, which may be, for example, a wired network such as Ethernet, a wireless network such as Wi-Fi, or a combination of wired and wireless networks. Not every device necessarily communicates with all the other devices. For example, the image processing and rendering system 12-5 may only communicate with imaging devices 12-1 and 12-4, but not with the excimer laser system 12-2 or the ablation system 12-3. Some interconnection communication paths may also be unidirectional; for example, imaging devices 12-1 and 12-4 may send imaging data to the image processing and rendering system 12-5, but the latter may not send data to imaging devices 12-1 and 12-4. Again, these are non-limiting illustrative examples.

[0030] Various devices 12-1, 12-2, 12-3, 12-4, 12-5 (or at least a portion thereof) generate log data recording the operation of their respective devices. Log data typically exists in the form of timestamped messages or events. Each device 12 records the log data it generates and typically does not record log data generated by other devices. For example, the C-arm X-ray imager 12-1 records events generated by or occurring at the C-arm X-ray imager 12-1, but not events or other occurrences at other devices 12-2, 12-3, 12-4, or 12-5. Furthermore, while each device 12 timestamps log entries created on that device, the timestamps may be created with reference to an internal clock, which may be out of sync with the clocks of other devices. Each device 12 may also record its log data using its own log data format, which may differ from the log data formats used by other devices in the IGT suite.

[0031] Some log entries for various devices 12 may reflect errors, malfunctions, or other problems that occurred while performing the IGT procedure using the IGT suite. These may be explicit, for example, the log entry may be an explicit error message; or they may be implicit, for example, the ablation system records low emitted laser power, failing to achieve the intended ablation of the blockage. Some errors recorded in the log of device "A" may actually be caused by a problem at another device "B". In the example mentioned above, ablation system 12-3 may record low emitted laser power, but this could actually be due to excimer laser system 12-2 not being powered on or not operating correctly. Some errors may be due to device malfunction (e.g., laser system 12-2 is not working and therefore does not provide laser, causing ablation system 12-3 to record low emitted laser power), while others may be due to operator error (e.g., the operator failed to turn on laser system 12-2, causing ablation system 12-3 to record low emitted laser power). Some errors may be interconnection communication errors. For example, laser system 12-2 may transmit its laser power to ablation system 12-3 via electronic network 13, and ablation system 12-3 may then record the laser power value received from laser system 12-2 via network 13 in the log of ablation system 12-3. In this case, an error in the network transmission of the laser power value from laser system 12-2 may cause an error in the laser power recorded by ablation system 12-3.

[0032] It is recognized in this document that many such errors may not be accurately identified by analyzing log data from a single device (e.g., ablation system 12-3), but can only be detected (or at least most definitively detected) by simultaneously analyzing log data from multiple devices 12-1, 12-2, 12-3, 12-4, 12-5, or certain subsets thereof, to detect a sequence of anomalous events (and their associated timestamps) occurring at two or more devices 12. As these examples illustrate, device 12 may also refer to a system, or in other words, the terms “device” and “system” are used interchangeably in this context. The monitoring device 10 disclosed herein performs such concurrent log data analysis while also handling normal time differences such as variations in how operators perform various operations in the IGT workflow (e.g., turning on laser 12-2, operating ablation system 12-3, acquiring IVUS images using IVUS system 12-4, etc.), as well as normal differences (or tolerances) in the timestamp annotation of log data by various devices 12.

[0033] like Figure 1 As shown, the monitoring device 10 includes or is accessible from a server computer 14, which is typically located remotely from the medical device 12. The server computer 14 includes a computer or other programmable electronic device that contains or is operable to access a non-transient computer-readable medium. The server computer 14 is connected via the Internet to… Medical device 12 communicates, optionally accompanied by one or more local area networks (LANs) or wide area networks (WANs) (which may include an exemplary electronic network 13 through which devices 12 communicate with each other), such as the LAN or WAN of the hospital where medical device 12 is located, and / or the LAN or WAN of the supplier or the cloud computing service provider that provides server computer 14 to the supplier. It should be understood that server computer 14 can be implemented as multiple server computers, for example, interconnected to form a server cluster, cloud computing resources, etc., to perform more complex computing tasks. In this way, log data 30 generated by the various devices 12 is transferred from the respective devices to server 14. More specifically, as Figure 1The diagram illustrates that: the C-arm X-ray imager 12-1 transmits its log data 30-1 to server 14; the excimer laser system 12-2 transmits its log data 30-2 to server 14; the ablation system 12-3 transmits its log data 30-3 to server 14; the IVUS system 12-4 transmits its log data 30-4 to server 14; and the image processing and rendering system 12-5 transmits its log data 30-5 to server 14. As previously mentioned, the various log datasets 12-1, 12-2, 12-3, 12-4, and 12-5 may have timestamp reference clocks that are not synchronized with each other, and furthermore, the various log datasets 12-1, 12-2, 12-3, 12-4, and 12-5 may use different log data formats.

[0034] Electronic processing device 18, such as a workstation computer, or more broadly, a computer, mobile device (e.g., a tablet computer), can be operated by a service engineer (SE), information technology (IT) professional, or similar personnel to provide a user interface to an alarm monitoring method or process 100 running on server computer 14. Electronic processing device 18 includes typical components for a user interface computer, such as an electronic processor 20 (e.g., a microprocessor), at least one user input device 22 (e.g., a mouse, keyboard, trackball, and / or similar device), and a display device 24 (e.g., a liquid crystal display, plasma display, cathode ray tube display, and / or the like). In some embodiments, display device 24 may be a separate component from electronic processing device 18 or may comprise two or more display devices. For displaying (one or more) color-coded images, display device 24 is preferably a color display device.

[0035] The non-transient storage medium 16 may include, by way of non-limiting illustrative example, one or more of the following: a disk, RAID, or other magnetic storage medium; a solid-state drive, a flash drive, an electronically erasable read-only memory (EEROM), or other electronic storage; an optical disk or other optical storage medium; various combinations thereof; and so on; for example, it may be a network storage device, the internal hard disk drive of the electronic processing device 18, and various combinations thereof. It should be understood that any reference herein to one or more non-transient media 16 should be broadly interpreted to cover a single medium or multiple media of the same or different types. Similarly, the electronic processor 20 may be implemented as a single electronic processor or two or more electronic processors. The non-transient storage medium 16 stores instructions that can be executed by at least one electronic processor 20. These instructions include instructions for generating a visualization of a graphical user interface (GUI) 28 for display on a display device 24.

[0036] The device 10 is configured as described above to execute a predictive maintenance method or process 100 for monitoring interconnection communication problems between medical systems 12(1) and (2) 12. The database 16 stores instructions that can be executed by the server computer 14 (and / or by the electronic processing device 18) to perform the monitoring method or process 100. In some examples, the method 100 may be executed at least partially by cloud processing (i.e., the server computer 16 may be implemented as a cloud computing resource comprising a self-organizing network of server computers).

[0037] refer to Figure 2 And continue to refer to Figure 1 An illustrative embodiment of an example of the predictive maintenance method 100 is schematically shown in the form of a flowchart. In operation 102, server computer 14 is configured to retrieve or receive log data 30 of events for each of the plurality of medical devices 12. The log data 30 is generated during a medical process employing the plurality of medical devices 12. In some embodiments, the medical process is an IGT process, and the plurality of medical devices 12 are medical devices of an IGT system. As previously described, each device 12 generates its own log data 30, which is transmitted to server 14 in operation 102. For example, C-arm X-ray imager 12-1 transmits its log data 30-1 to server 14; excimer laser system 12-2 transmits its log data 30-2 to server 14; ablation system 12-3 transmits its log data 30-3 to server 14; IVUS system 12-4 transmits its log data 30-4 to server 14; and image processing and rendering system 12-5 transmits its log data 30-5 to server 14.

[0038] At step 104, log data 30-1, 30-2, 30-3, 30-4, and 30-5 from the respective medical devices 12-1, 12-2, 12-3, 12-4, and 12-5 are synchronized in time. For this purpose, server computer 14 is configured to identify timestamped events in the log data 30 of at least two or more medical devices 12 that correspond to events with known time synchronization during the medical process. The timestamps of the log data 30 from at least one of the two or more medical devices 12 are adjusted based on a comparison of the timestamps of the timestamped events with known time synchronization.

[0039] In operation 106, portions of log data 30 from two or more of the plurality of medical devices 12 are compared with a context representing expected interactions between the two or more medical devices 12 during a medical procedure. In some embodiments, the server computer 14 is configured to compare events in portions of the log data 30 with a context containing a sequence of expected events expected to occur during the medical procedure. In other embodiments, the server computer 14 is configured to adjust the format or structure of the log data 30 of at least one of the plurality of medical devices 12 to match the format or structure of another medical device among the plurality of medical devices 12.

[0040] In some embodiments, the comparison operation 106 includes applying one or more diagnostic rules 32 to portions of log data 30. The diagnostic rules 32 are stored in a database 16. In some embodiments, one or more parameters of the one or more diagnostic rules 32 are adjusted based on historical log data generated from past medical procedure instances. For example, this adjustment can accommodate normal operator-to-operator time variations during IGT procedures while also detecting anomalous event sequences. To adjust the parameters, a machine learning (ML) model 34 (stored in the database 16) is trained on the historical log data to distinguish between historical log data marked as having errors to be detected (positive samples) and historical log data marked as not having errors to be detected (negative samples). This training is used to adjust one or more parameters of the diagnostic rules 32. The diagnostic rules 32 with the adjusted one or more parameters are applied to various portions of the log data 30. The portions of log data 30 to which a given diagnostic rule 32 is applied can be selected, for example, portions containing events to be analyzed by that rule. For example, rule 32, used to detect that the laser is turned on too late, can be applied to parts of the log data, including events related to that timing in the log data 30-2 of the laser system 12-2 and the log data 30-3 of the ablation system 12-3.

[0041] In operation 108, one or more interconnect communication errors between two or more of the plurality of medical devices 12 are detected based on comparison operation 106. In some embodiments, server computer 14 is configured to determine a failure of one of the plurality of medical devices 12 based on the detected one or more interconnect communication errors. The failure of the one medical device 12 is determined by inputting a portion of the log data 30 of the two or more medical devices 12 into a machine learning model 34 to identify the root cause of the one or more interconnect communication errors.

[0042] In operation 110, an alarm 36 identifying the one or more interconnect communication errors is output, for example, on display device 24. The output alarm 36 associates one or more interconnect communication errors with a identified malfunction of a medical device 12. example

[0043] The apparatus 10 and method 100 are described in more detail below. Apparatus 10 focuses on the operational-related technical work required to contextualize the machine logs of multiple devices so that an effective predictive maintenance model can be developed. One of the main challenges in contextualizing the logs of multiple devices is the time synchronization of their machine logs. This is not a simple task, and asynchronous log files make it impossible to infer the context of a specific error message generated by a device. To address the time synchronization problem, background knowledge regarding the structure and content of the log files is combined with machine learning. Background knowledge is used to understand which machine operations should cause log messages to occur simultaneously at multiple devices. Due to the hardware differences of these devices, this process may introduce some ambiguities, such as how much time difference tolerance should be considered normal. Machine learning techniques are used to address these ambiguities.

[0044] While this document primarily describes the IGT suite, the disclosed methods can be applied to other types of imaging suites employing interconnected communication devices. In the context of a hospital setting, the IGT system can be referred to as the "parent," and the "add-on" product as the "child." This add-on product can be anything, from IWS to Intrasight. ® wait.

[0045] For any IGT device 12, the detailed reports generated and stored regarding significant hardware and software events are called log files 30. Therefore, each log file contains a large number of events. Each event includes an event ID and some text (called a description) to explain the event. During the lifecycle of the IGT (or any product), software versions change, and the logged events also change. Therefore, events may have different descriptions in different software versions of the same product. Similarly, there may be a small number of event IDs that are logged only in a few specific software versions. Therefore, log lines between different software versions are obviously inconsistent.

[0046] Connection detection between parent and child devices can have several causes. One such cause could be a startup / shutdown issue. Both the parent and child have their own power cycle schedules. The two systems are connected to mains power independently. This independence means that various scenarios are possible, such as the parent system being running while the child system is not. This situation can cause the parent system to generate numerous error messages because the child system is unavailable. Startup / shutdown is merely an additional method and cannot, on its own, identify a connection between parent and child. Log messages associated with startup and shutdown can sometimes be misleading because one of them may not be running. For these reasons, startup or shutdown is not a reliable method for detecting connection between parent and child log lines.

[0047] Another possible reason for connection detection between parent and child devices is the start of a medical procedure or examination. There is a communication mechanism between the parent and child, where the child is the slave device responding to each request arriving at it. Such a request might be the start of a new examination. The subsystem doesn't respond to this request but instead performs some internal setup and adds a log line to the subsystem's log file. This log line is a key element proving the active connection. It's important to note that the examination name is encrypted, which largely makes distinguishing examination identifiers difficult. Therefore, this method requires some additional effort (adding other methods) to become complete.

[0048] Another possible reason for detecting a connection between the parent and child devices is the selection of a medical procedure. Another parent-child communication concerns procedure changes. The child's response is that if it recognizes the procedure, it will perform some internal setup. If it cannot recognize the procedure, this will be stated in the log line. A unique feature of procedure selection is that it can be triggered from the child, thus reaching the parent. This means we could start connecting the child's log line to the parent. However, this is a rare (child-to-parent) event, making it not a convenient log line / message for interconnect identification.

[0049] Another possible reason for connectivity detection between parent and child devices is application selection. Application selection typically begins with the parent and then proceeds to the child. Applications may have selections that do not require / do not involve the subsystem level. This can be misleading because there is usually no separate log line stating whether the subsystem level should not be involved or whether the subsystem level is corrupted. This makes this log line section rather unreliable in identifying interconnections.

[0050] Another possible reason for detecting connectivity between parent and child devices is the "run tag / CWIS code method." This method relies on a unique set of characters to identify a set of communications and thus finds a unique set of log lines that can indicate the interconnection between parent and child. The problem is that sometimes these run tags or code identifiers are not mentioned in the parent log lines. Therefore, it has proven to be a reliable, but not a standalone, method for finding interconnections between parent and child.

[0051] As mentioned earlier, each of these five methods has its advantages and disadvantages. Combining these methods can identify relationships between parent and child log lines. In the first example, subsystem-level check runs (i.e., example IWS runs) are identified to find the time differences between runs t1, t2, etc. Next, IWS-based runs at the parent system level are identified to find the time differences between runs T1, T2, etc. The subsystem's run patterns (i.e., time-based patterns) are matched with the master / parent system's patterns over a one-month period. At least two such pattern matches between the subsystem and the parent system confirm the run and response log lines, and these log lines can be selected as interconnection locations.

[0052] Use the following rules to synchronize logs between the IWS and IXR devices. Extract the timestamps of the following two IWS log messages:<IWS_Timestamp> Message A: Event ID='123456Import', and the description begins with "New EPX selected"; Message B: Event ID='123456789123', and the description begins with "iAssets.Infra.Domain.XrayModality.CwisDvlp.Orchestrator:SendValidationResultToXraySystem".

[0053] The timestamp included in the description of the above message<Extracted_Timestamp> It will also be extracted. For message A, the timestamp is included after "id=.". For message B, the timestamp is included after "Epx=".

[0054] Differences in the use of timestamps in IWS log messages<IWS_Timestamp> -<Extracted_Timestamp> Update as needed. If multiple time differences are detected within a day, the smallest time difference is used.

[0055] IWS messages <Message A> and <Message B> can be initiated via IXR messages with EventIDs (process and application selection). {'123456789','987654321','192837465','12HJIRD9876543','45JFBMR45678962'}. Extract the timestamps of these messages from the IXR logs and compare them to the IWS timestamps of <Message A> and <Message B>. If the difference is greater than 10 minutes, discard all logs for that day.

[0056] When both are functioning correctly, log messages from the IWS and IXR logs will be used. When we detect a shutdown process being initiated in one of the two logs, messages from both will be filtered out.

[0057] In the time synchronization process described above, we can see that several parameters / selections need to be made. For example, in method B, step 5 states: "If the difference is greater than 10 minutes, then we discard all logs for that day." This parameter, along with other parameters in the time synchronization process, is optimized using machine learning methods, taking into account past customer reports of interconnection communication problems between their IGT devices.

[0058] The machine learning process may involve using customer calls that report interconnect communication problems, and collecting data before the customer calls and after the interconnect communication problems are resolved. Data before the customer calls should contain message patterns associated with the reported problems, while data after the calls should not contain such patterns. This data can guide the correct parameter selection, because, for example, an error message that appears after the problem is resolved might be interpreted as one of the other connected devices simply being turned off. This information / context can help us identify the correct time synchronization parameters. The machine learning model 34 uses different time synchronization parameter configurations, and ultimately selects the configuration that optimizes model performance.

[0059] Suboptimal time synchronization parameters may incorrectly indicate that both devices are enabled, triggering false alarms. This will be captured as a false alarm prediction, thus degrading the performance of machine learning model 34.

[0060] This disclosure has been described with reference to preferred embodiments. Various modifications and variations can be made by those skilled in the art upon reading and understanding the foregoing detailed description. The exemplary embodiments are intended to be understood to include all such modifications and variations, provided they fall within the scope of the appended claims or their equivalents.

Claims

1. A non-transient computer-readable medium (16) storing instructions capable of being read and executed by an electronic processor (14) to perform a predictive maintenance method (100), the predictive maintenance method comprising: Retrieve log data (30) of events generated during a medical process employing multiple medical devices (12). A portion of the log data from two or more of the plurality of medical devices is compared with a context representing the expected interconnection communication between the two or more medical devices during the medical procedure; Based on the comparison, one or more interconnection communication errors between two or more of the plurality of medical devices are detected; as well as Output an alarm (36) that identifies one or more interconnect communication errors.

2. The non-transient computer-readable medium (16) according to claim 1, wherein, The method (100) further includes: The log data (30) of the plurality of medical devices (12) is synchronized in time, wherein the detection is performed on the log data after the synchronization.

3. The non-transient computer-readable medium (16) according to claim 2, wherein, The synchronization includes: Identify timestamped events in the log data (30) of the two or more medical devices (12) that correspond to events with known time synchronization during the medical procedure; and Based on a comparison between the timestamp of the timestamped event and the known time synchronization, the timestamp of the log data of at least one of the two or more medical devices is adjusted.

4. The non-transient computer-readable medium (16) according to any one of claims 1-3, wherein, The method (100) further includes: Prior to the detection, the format or structure of the log data (30) of at least one of the plurality of medical devices (12) is adjusted to match the format or structure of another of the plurality of medical devices.

5. The non-transient computer-readable medium (16) according to any one of claims 1-4, wherein, Comparing the portion of the log data (30) of the two or more medical devices (12) with the context includes: The events in the portion of the log data are compared with the context of an expected sequence of events that are expected to occur in the medical process.

6. The non-transient computer-readable medium (16) according to any one of claims 1-5, wherein, Comparing the portion of the log data (30) of the two or more medical devices (12) with the context includes: Apply one or more diagnostic rules (32) to the portion of the log data.

7. The non-transient computer-readable medium (16) according to claim 6, wherein, The method (100) further includes: Based on historical log data generated from past instances of the medical process, adjust one or more parameters of the one or more diagnostic rules (32); The one or more diagnostic rules with one or more adjusted parameters are applied to the portion of the log data (30).

8. The non-transient computer-readable medium (16) according to claim 7, wherein, The adjustment of one or more parameters of the diagnostic rule (32) includes: A machine learning (ML) model (34) trained on the historical log data is applied to adjust one or more parameters of the diagnostic rules.

9. The non-transient computer-readable medium (16) according to any one of claims 1-8, wherein, The method (100) further includes: Based on the detected one or more interconnect communication errors, a fault is determined in one of the plurality of medical devices (12); The output alarm (36) associates the one or more interconnect communication errors with a known fault of the medical device.

10. The non-transient computer-readable medium (16) according to claim 9, wherein, The failure of one medical device is determined by inputting portions of the log data of the two or more medical devices into a machine learning (ML) component (34) to identify the root cause of the one or more interconnect communication errors, the machine learning (ML) component being trained on historical log data generated from past instances of the medical process.

11. The non-transient computer-readable medium (16) according to any one of claims 1-10, wherein, Outputting the alarm (34) includes: The alarm is displayed on the display device (24).

12. The non-transient computer-readable medium (16) according to any one of claims 1-11, wherein, The medical process is an image-guided therapy (IGT) process, and the plurality of medical devices (12) are medical devices of the IGT system.

13. A non-transient computer-readable medium (16) storing instructions capable of being read and executed by an electronic processor (14) to perform a predictive maintenance method (100), the predictive maintenance method comprising: Retrieve log data (30) of events generated during a medical process employing multiple medical devices (12). One or more diagnostic rules (32) are applied to portions of the log data of the two or more medical devices in the plurality of medical devices using a context representing the expected interconnection communication between the two or more medical devices during the medical procedure; Based on the comparison, one or more interconnection communication errors between two or more of the plurality of medical devices are detected; as well as Output an alarm (36) that identifies one or more interconnect communication errors.

14. The non-transient computer-readable medium (16) according to claim 13, wherein, The method (100) further includes: The log data (30) of the plurality of medical devices (12) is synchronized in time, wherein the detection is performed on the log data after the synchronization.

15. The non-transient computer-readable medium (16) according to claim 14, wherein, The synchronization includes: Identify timestamped events in the log data (30) of the two or more medical devices (12) that correspond to events with known time synchronization during the medical procedure; and Based on a comparison between the timestamp of the timestamped event and the known time synchronization, the timestamp of the log data of at least one of the two or more medical devices is adjusted.

16. The non-transient computer-readable medium (16) according to any one of claims 13-15, wherein, The method (100) further includes: Prior to the detection, the format or structure of the log data (30) of at least one of the plurality of medical devices (12) is adjusted to match the format or structure of another of the plurality of medical devices.

17. The non-transient computer-readable medium (16) according to any one of claims 13-16, wherein, The method (100) further includes: Based on historical log data generated from past instances of the medical process, adjust one or more parameters of the one or more diagnostic rules (32); The one or more diagnostic rules with one or more adjusted parameters are applied to the portion of the log data (30).

18. The non-transient computer-readable medium (16) according to claim 17, wherein, The adjustment of one or more parameters of the diagnostic rule (32) includes: A machine learning (ML) model (34) trained on the historical log data is applied to adjust one or more parameters of the diagnostic rule.

19. The non-transient computer-readable medium (16) according to any one of claims 13-18, wherein, The method (100) further includes: Based on the detected one or more interconnect communication errors, a fault is determined in one of the plurality of medical devices (12); The output alarm (36) associates the one or more interconnect communication errors with a known fault of the medical device.

20. A predictive maintenance method (100), comprising: Retrieve log data (30) of events generated during a medical process employing multiple medical devices (12). Identify timestamped events in the log data (30) of the two or more medical devices (12) that correspond to events with known time synchronization during the medical process; Based on a comparison between the timestamp of the timestamped event and the known time synchronization, the timestamp of the log data of at least one of the two or more medical devices is adjusted; A portion of the log data from two or more of the plurality of medical devices is compared with a context representing the expected interconnection communication between the two or more medical devices during the medical procedure; Based on the comparison, one or more interconnection communication errors between two or more of the plurality of medical devices are detected; as well as Output an alarm (36) that identifies one or more interconnect communication errors.

Images