Systems and methods for enabling predictive maintenance for intercommunication issues in exam room

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 medical devices of the plurality of medical devices with a context representing an expected intercommunication between the two or more medical devices during the medical procedure; detecting one or more intercommunication errors between two or more medical devices of the plurality of medical devices based on the comparing; and outputting an alert (36) identifying the one or more intercommunication errors.

Description

SYSTEMS AND METHODS FOR ENABLING PREDICTIVE MAINTENANCE FOR INTERCOMMUNICATION ISSUES IN EXAM ROOMFIELD

[0001] The following relates generally to the device and systems monitoring arts, medical device maintenance arts, predictive maintenance arts, inter-device communication arts, image guided therapy (IGT) suite maintenance arts, and related arts.BACKGROUND

[0002] A modem medical system, such as an IGT suite, includes many interacting electronic components, such as an X-ray system itself, associated therapy devices such as excimer laser and / or aspiration systems, and enhanced visualization devices such as intravenous ultrasound (IVUS) and image rendering systems. Successful interventional therapy relies on these systems effectively interacting with each other.

[0003] Problems can arise in a given device, but such a problem may manifest as an observed problem with some other device. Typically, predictive maintenance diagnostics operate on a per-device basis, and are less effective or ineffective at detecting incipient problems with interaction between devices.

[0004] For example, image guided therapy (IGT) systems typically include at least one imaging sub-system such as a C-arm X-ray imaging gantry and a patient table and / or an intravascular ultrasound (IVUS) system, therapy-related subsystems to perform intravascular catheter insertion and intravascular therapy operations such as laser ablation, stent implantation, or so forth, and are used for performing image-guided interventions such as intravascular stent implants, atherectomies, thrombectomies, and so forth. Examples of such systems include the Philips Azurion® and Allura® lines of interventional X-ray systems.

[0005] Auxiliary components operate in conjunction with such IGT systems. For example, in some IGT suites available from Koninklijke Philips N.V., Spectranetics® excimer lasers may be used to drive laser ablation catheters, Intrasight® intravascular ultrasound (IVUS) systems provide an additional image modality for the image-guided therapy, and advanced visualization systems such as Philips’ Interventional Workspot (IWS) can provide improved image rendering capability for an X-ray system. Other illustrative examples of systems that may be used in the IGT context could include automated aspiration systems and so forth.

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

[0007] In some embodiments disclosed herein, a non-transitory computer readable medium stores instructions readable and executable by an electronic processor to perform a predictive maintenance method. The predictive maintenance method includes retrieving log data of events of a plurality of medical devices generated during a medical procedure employing the plurality of medical devices; comparing portions of the log data of two or more medical devices of the plurality of medical devices with a context representing an expected intercommunication between the two or more medical devices during the medical procedure; detecting one or more intercommunication errors between two or more medical devices of the plurality of medical devices based on the comparing; and outputting an alert identifying the one or more intercommunication errors.

[0008] In some embodiments disclosed herein, a non-transitory computer readable medium stores instructions readable and executable by an electronic processor to perform a predictive maintenance method including retrieving log data of events of a plurality of medical devices generated during a medical procedure employing the plurality of medical devices; applying one or more diagnostic rules to portions of the log data of two or more medical devices of the plurality of medical devices using a context representing an expected intercommunication between the two or more medical devices during the medical procedure; detecting one or more intercommunication errors between two or more medical devices of the plurality of medical devices based on the comparing; and outputting an alert identifying the one or more intercommunication errors.

[0009] In some embodiments disclosed herein, a predictive maintenance method includes retrieving log data of events of a plurality of medical devices generated during a medical procedure employing the plurality of medical devices; identifying timestamped events in the log data of the two or more medical devices corresponding with events during the medical procedure having known time synchronization; adjusting time stamps of the log data of at least one of the two or more medical devices based on a comparison between the time stamps of the timestamped events and the known time synchronization; comparing portions of the log data of two or more medical devices of the plurality of medical devices with a context representing an expectedintercommunication between the two or more medical devices during the medical procedure; detecting one or more intercommunication errors between two or more medical devices of the plurality of medical devices based on the comparing; and outputting an alert identifying the one or more intercommunication errors.

[0010] One advantage resides in generating predictive maintenance models for a plurality of medical devices based on intercommunication between the medical devices.

[0011] Another advantage resides in reducing false positive alerts between medical devices of a plurality of medical devices.

[0012] Another advantage resides in identifying intercommunication issues between multiple medical devices.

[0013] Another advantage resides in applying machine-learning (ML) models to identify a root cause of intercommunication issues between multiple medical devices.

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

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

[0016] FIGURE 1 diagrammatically illustrates a predictive maintenance apparatus in accordance with the present disclosure.

[0017] FIGURE 2 diagrammatically illustrates an alert monitoring method using the apparatus of FIGURE 1.DETAILED DESCRIPTION

[0018] The following discloses approaches for providing inter-operability diagnostics between medical devices. The approach leverages the log data files generated by the various devices. While primarily described herein in reference to IGT suites, the disclosed approaches could apply to other types of imaging suites that employ intercommunicating devices.

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

[0020] To generate diagnostic engines for detecting intercommunication issues between the devices of the IGT suite, historical log data are analyzed to determine normal event sequences during interventional procedures, with each event sequence being made up of timestamped events logged at the various devices. A priori knowledge of the expected interventional procedure workflow serves as the basis of diagnostic rules for detecting abnormal event sequences that could trigger a maintenance alert. An event sequence could be abnormal in various ways, such as by having one or more device logs containing affirmative error messages, or having events at different devices that should be simultaneous occurring at different times, or having successive events at different devices delayed by an undue amount of time, or so forth.

[0021] However, even in normal operation the timing between events occurring at different devices may vary significantly from one instance of the interventional procedure to the next. This cannot be fully accommodated by synchronizing the log data of the different devices in time, because the actual timing of the logged events can vary. Different operators may perform a sequence of actions with different time differences between the actions, or events such as the time to ablate a lesion or the time for the operator to accurately place a stent in the blood vessel can vary from procedure to procedure, thus introducing normal time difference variations between events. On the other hand, an intercommunication problem between devices can introduce abnormal time differences. For example, a communication bus problem may cause undue delay between successive events at different devices, and it is these abnormal time differences that should trigger a maintenance alert.

[0022] Hence, the diagnostic rule is formulated in a parameterized way, with time intervals and potentially other aspects of the sequence being adjustable parameters. Machine learning (ML) or other analytics then optimize the parameters using historical service case data to generate tuned rules for the expected sequences of log events in an interventional procedure. The tuned rule is then effective to distinguish abnormal time differences that should trigger proactive maintenance (e.g., fixing a communication bus) from a normal range of time differences.

[0023] Some problems may be difficult to capture with a rules-based diagnostic. For example, error messages generated by one device could in fact be due to a problem with anotherdevice or could be due to an intercommunication issue. As an example, if the IGT system monitors laser power during a laser ablation procedure, then an error indicating low (or no) laser power at the start of a laser ablation procedure might not be a problem with the IGT system, but rather could be due to a problem with the excimer laser device, or a problem with the communication bus which delays the startup of the excimer laser device. Still further, some error messages may be due to operator error rather than a maintenance issue. For example, an error message that the laser is not operating could be due to the operator failing to turn on the laser.

[0024] Thus, some diagnostic models may be implemented as machine learning (ML) models such as artificial neural network (ANN) models. These models are suitably trained on historical service cases to identify abnormal event sequences with malfunctions in specific devices or a problem with intercommunication between specific devices. The input to these models is historical log data (or features derived therefrom) from the logs of the various devices of the IGT suite, labeled with the maintenance issues identified by maintenance personnel in these historical cases. Some negative training samples may be provided as log data from the various devices of the IGT suite collected during normal interventional procedures for which there are no identified maintenance issues.

[0025] In the inference phase, log data from the devices of the IGT suite are uploaded to the server computer and are synchronized in time and format, and the synchronized log data are input to the tuned diagnostic rules and trained ML diagnostic models to detect possible maintenance problems.

[0026] The disclosed system can be used to proactively detect problems, such as a problem with one device of the IGT suite that may manifest as error messages or warnings in the log data of another device, or a problem with intercommunication between the devices. In this application, the identified problems are maintenance problems, and the outputs are maintenance alerts suitably directed to a service engineer.

[0027] In some embodiments, the diagnostic models are applied to detect a problem in the usage of the devices. For example, the models could generate an alert if the log data from the devices of the IGT suite indicate that the operators are frequently turning on the excimer laser at the wrong point in time in the interventional procedure. In this case the output could be sent to a representative of the radiology department, for example formulated as a suggestion to reviewtraining on the usage of the excimer laser and perhaps attaching the operating instructions (or a relevant portion thereof).

[0028] While primarily described herein in reference to IGT suites, the disclosed approaches could apply to other types of imaging suites that employ intercommunicating devices. For example, positron emission tomography (PET), magnetic resonance imaging (MRI), and some other modalities utilize delivery of an intravascular contrast agent during a diagnostic imaging procedure, with the imaging sequences being closely timed with the inflow and washout of the contrast agent into and out of the anatomy of interest. In MRI, local coils may be utilized which employ wireless communication with the MRI scanner. The diagnostic monitoring of the present ID is readily applicable to such situations, for example for detecting a communication problem between the intravascular contrast agent injector device and the MRI scanner controller, or between a wireless local coil and the MRI scanner.

[0029] With reference to FIGURE 1, an illustrative apparatus 10 for monitoring intercommunication issues between a plurality of associated medical devices or systems 12 is shown. While primarily described herein in reference to IGT suites, the disclosed approaches could apply to other types of imaging suites that employ intercommunicating devices. The medical devices 12 can comprise, for example, n medical imaging devices 12 and / or components thereof. In the illustrative example, n=5 and the illustrative medical devices 12 include: a C-arm X-ray imager 12-1 for providing image guidance during insertion of a catheter into a blood vessel for an intravascular laser ablation therapy procedure; an excimer laser system 12-2; an ablation system 12-3 for performing laser ablation of a blood vessel 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 rendering system 12-5 for processing, optionally fusing, and displaying images from the C-arm X-ray and IVUS systems. These devices are nonlimiting illustrative typical devices making up an image guided therapy (IGT) suite used to perform intravascular laser ablation of a blood clot or other blood vessel occlusion. While five imaging devices 12-1, 12-2, 12-3, 12-4, and 12-5 are shown in FIGURE 1, any suitable number of n medical imaging devices 12 can be included, and in some embodiments n may be 2, 3, 4, 5, 6, 8, 10, 12, dozens, or more medical imaging devices, as further nonlimiting illustrative examples. As diagrammatically shown in FIGURE 1, the devices 12-1, 12-2, 12-3, 12-4, 12-5 intercommunicate with each other over an electronic network 13, which may forexample be a wired network such as an Ethernet, a wireless network such as Wi-Fi, or a combination of wired and wireless networks. Not every device necessarily communicates with every other device. For example, the image processing and rendering system 12-5 may intercommunicate only with the imaging devices 12-1 and 12-4, but not with the excimer laser system 12-2 or ablation system 12-3. Some intercommunication pathways may also be unidirectional, e.g., the 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 the imaging devices 12-1 and 12-4. Again, these are nonlimiting illustrative examples.

[0030] The various devices 12-1, 12-2, 12-3, 12-4, 12-5 (or at least a subset thereof) generate log data recording operation of the respective devices. The log data are typically in the form of messages or events or the like that are timestamped. Each device 12 records log data generated by that device, and generally does not record log data generated by other devices. For example, the C-arm X-ray imager 12-1 logs events generated by or otherwise occurring at the C-arm X-ray imager 12-1, but does not log events or other occurrences at the other devices 12-2, 12-3, 12-4 , or 12-5. Moreover, while each device 12 timestamps log entries made at that device, the timestamps may be made referenced to an internal clock that may not be synchronized in time with the clocks of the other devices. Each device 12 may also record its log data using its own log data format which may differ from the log data format used by other devices of the IGT suite.

[0031] Some log entries of the various devices 12 may reflect errors, malfunctions, or other problems occurring in an IGT procedure performed using the IGT suite. These may be explicit, e.g., the log entry could be an explicit error message; or, these may be implicit, e.g., the ablation system recording a transmitted laser power that is too low to achieve desired ablation of an occlusion. Some errors recorded in the log of one device “A” could actually be due to a problem at another device “B.” In the just-mentioned example, the low transmitted laser power might be recorded by the ablation system 12-3 but could actually be due to the excimer laser system 12-2 not being turned on or otherwise not operating properly. Some errors could be due to equipment malfunction (e.g., the laser system 12-2 being inoperative and thus not providing laser light leading to the ablation system 12-3 recording low transmitted laser power) while some errors could be due to operator error (e.g., the operator fails to turn on the laser system 12-2 thus leading to the ablation system 12-3 to record low transmitted laser power). Some errors could be intercommunication errors, e.g. the laser system 12-2 might transmit its laser power to the ablation system 12-3 via theelectronic network 13 and the ablation system 12-3 then records the laser power value received from the laser system 12-2 via the network 13 in the log of the ablation system 12-3 - in this case, an error in the network transmission of this laser power value from the laser system 12-2 could lead to an error in the laser power recorded by the ablation system 12-3.

[0032] As recognized herein, many of these types of errors may not be accurately determined by analysis of the log data of a single device (e.g. the ablation system 12-3), but rather are only detectable (or at least most unambiguously detectable) by concurrent analysis of the log data of the multiple devices 12-1, 12-2, 12-3, 12-4, 12-5 or some subset thereof to detect an abnormal sequence of events (and their associated timestamps) occurring at two or more of the devices 12. As illustrated by these examples, a device 12 could also be a system, or put otherwise, the terms “device” and “system” are used interchangeably in this respect. The monitoring apparatus 10 disclosed herein performs such concurrent log data analysis, while accommodating challenges such as ordinary differences in timing in the IGT workflow due to inter-operator differences in how the operator performs various operations (e.g., turning on the laser 12-2, operating the ablation system 12-3, acquiring IVUS images with the IVUS system 12-4, et cetera) and normal differences (or tolerances) in timestamping of log data performed by the various devices 12.

[0033] As shown in FIGURE 1, the monitoring apparatus 10 includes, or is accessible by, a server computer 14 typically disposed remotely from the medical devices 12. The server computer 14 comprises a computer or other programmable electronic device that includes or has operative access to a non-transitory computer readable medium. The server computer 14 communicates with the n medical devices 12 via the Internet, optionally along with one or more local area networks (LAN) or wide-area networks (WAN) (which could include the illustrative electronic network 13 via which the devices 12 intercommunicate amongst themselves), such as a LAN or WAN of the hospital at which the medical devices 12 is located, and / or a LAN or WAN of the vendor or of a cloud computing service provider providing the server computer 14 to the vendor. It will be appreciated that the server computer 14 could be implemented as a plurality of server computers, e.g., interconnected to form a server cluster, cloud computing resource, or so forth, to perform more complex computational tasks. In this way, the log data 30 generated by the various devices 12 are transmitted from the respective devices to the server 14. More particularly, as diagrammatically illustrated in FIGURE 1 : the C-arm X-ray imager 12-1 transmits its log data30-1 to the server 14; the excimer laser system 12-2 transmits its log data 30-2 to the server 14; the ablation system 12-3 transmits its log data 30-3 to the server 14; the IVUS system 12-4 transmits its log data 30-4 to the server 14; and the image processing and rendering system 12-5 transmits its log data 30-5 to the server 14. As previously noted, the various log data sets 12-1, 12-2, 12-3, 12-4, and 12-5 may have time stamp reference clocks that are not mutually synchronized, and furthermore the various log data sets 12-1, 12-2, 12-3, 12-4, and 12-5 may employ different log data formats.

[0034] An electronic processing device 18, such as a workstation computer, or more generally a computer, a mobile device (e.g., a tablet computer), is operable by a service engineer (SE), information technology (IT) professional, or the like to provide a user interface with an alert monitoring method or process 100 running on the server computer 14. The electronic processing device 18 includes typical components for a user interfacing computer, such as an electronic processor 20 (e.g., a microprocessor), at least one user input device (e.g., a mouse, a keyboard, a trackball, and / or the like) 22, and a display device 24 (e.g., an LCD display, plasma display, cathode ray tube display, and / or so forth). In some embodiments, the display device 24 can be a separate component from the electronic processing device 18 or may include two or more display devices. To display color-coded image(s), the display device 24 should preferably be a color display device.

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

[0036] The apparatus 10 is configured as described above to perform a predictive maintenance method or process 100 of monitoring intercommunication issues between the medical system(s) 12. The database 16 stores instructions executable 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 performed at least in part by cloud processing (that is, the server computer 16 may be implemented as a cloud computing resource comprising an ad hoc network of server computers).

[0037] With reference to FIGURE 2, and with continuing reference to FIGURE 1, an illustrative embodiment of an instance of the predictive maintenance method 100 is diagrammatically shown as a flowchart. At an operation 102, the server computer 14 is configured to retrieve or receive the log data 30 of events of the various medical devices 12 of the plurality of medical devices 12. The log data 30 is generated during a medical procedure employing the plurality of medical devices 12. In some embodiments, the medical procedure is an IGT procedure and the plurality of medical devices 12 are medical devices of an IGT system. As previously mentioned, each device 12 generates its own log data 30 which is transmitted to the server 14 in the operation 102, e.g. the C-arm X-ray imager 12-1 transmits its log data 30-1 to the server 14; the excimer laser system 12-2 transmits its log data 30-2 to the server 14; the ablation system 12-3 transmits its log data 30-3 to the server 14; the IVUS system 12-4 transmits its log data 30-4 to the server 14; and the image processing and rendering system 12-5 transmits its log data 30-5 to the server 14.

[0038] At an operation 104, the 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 is synchronized in time. To do so, the server computer 14 is configured to identify timestamped events in the log data 30 of at least two or more medical devices 12 corresponding with events during the medical procedure having known time synchronization. Time stamps of the log data 30 of at least one of the two or more medical devices 12 are adjusted based on a comparison between the time stamps of the timestamped events and the known time synchronization.

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

[0040] In some embodiments, the comparing operation 106 includes applying one or more diagnostic rules 32 to the portions of the log data 30. The diagnostic rules 32 are stored in the database 16. In some embodiments, one or more parameters of the one or more diagnostic rules 32 are tuned based on historical log data generated by past instances of the medical procedure. Such tuning can, for example, accommodate normal inter-operator timing differences in executing an IGT procedure, while still detecting abnormal event sequences. To tune the parameters, a machine-learning (ML) model 34 (stored in the database 16) is trained on the historical log data to distinguish historical log data labeled as having the error to be detected (positive examples) from historical log data labeled as not having the error to be detected (negative examples). This training operates to tune the one or more parameters of the diagnostic rules 32. The diagnostic rule(s) 32 with the tuned one or more parameters are applied to the portions of the log data 30. The portions of the log data 30 to which a given diagnostic rule 32 is applied can be selected as, for example, a portion having the events that are to be analyzed by the rule. For example, a rule 32 to detect the laser being turned on too late might be applied to portions of the log data including events related to this 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] At an operation 108, one or more intercommunication errors between two or more medical devices of the plurality of medical devices 12 are detected based on the comparing operation 106. In some embodiments, the server computer 14 is configured to determine a malfunction of one medical device of the plurality of medical devices 12 based on the detected one or more intercommunication errors. The malfunction of the one medical device 12 is determined by inputting the portions of the log data 30 of the two or more medical devices 12 to the ML model 34 to identify a root cause of the one or more intercommunication errors.

[0042] At an operation 110, an alert 36 identifying the one or more intercommunication errors is output, for example, on the display device 24. The output alert 36 associates the one or more intercommunication errors with the determined malfunction of the one medical device 12.EXAMPLE

[0043] The following describes the apparatus 10 and the method 100 in more detail. The apparatus 10 focuses on the technical work that is related to the actions that are needed to put multiple device machine logs in context such that effective predictive maintenance models can be developed. One main challenge for putting multiple device logs in context is time-synchronization of their machine logs. This is a non-trivial task and non-synchronized log files make it impossible to infer the context around a specific error message generated by one device. In order to address the time-synchronization problem, background knowledge about the structure and contents of the log files are combined with machine learning. Background knowledge is used to understand which machine operations result in log messages in multiple devices that should occur at the same time. This process can result in some ambiguities that are related for example to how much timedifference tolerance should be considered as normal due to the hardware differences of these devices. Machine learning techniques are used to resolve these ambiguities.

[0044] While primarily described herein in reference to IGT suites, the disclosed approaches could apply to other types of imaging suites that employ intercommunicating devices. In a hospital setup context, an IGT system can be referred to as “the parent” and an ‘add on’ product as “the child.” This add-on product can be anything from an IWS to Intrasight® etc.

[0045] For any IGT device 12, the detailed reports on important hardware and software events that are generated and stored are called log files 30. Each logfile thus comprise of numerous events. Each event contains an event-ID and some text (called description) to explain the event. Over the lifecycle of IGT (or any product) the software versions change and so does the events which are logged. An event can therefore have different descriptions in different software versions of same product. Similarly, there might be few event-ID’ s which are logged only in few specific software versions. Loglines therefore are apparently inconsistent across the software versions.

[0046] There are many possible causes of connection detection between the parent device and the child device. One such cause can be start-up / shut-down issues. The parent as well as the child have their own power cycle schedule. The connection to mains power of both systems is independent. This independency means that several scenarios are possible for example the parent is operational and the child is not. This situation leads to the fact that the parent starts to produce many error messages because the child is not available. The start-up / shutdown connection is only an add on method, it cannot by itself identify a connection between parent and child. The logmessages related to start and shut down at times may be misleading as one of them might be non- operational. For these reasons, the startup or shutdown are not a reliable way to connect the log lines of parent and child.

[0047] Another possible cause of connection detection between the parent device and the child device can be the start of the medical procedure or exam. The parent and the child have a form of communication in which the child is a slave that answers every request that reaches him. Such a request can be the start of a new exam. The child will not answer this request but only do some internal settings and add a logline in the child’s logfile. This logline is a key proof element of a live connection. The caveat is that the exam names are encrypted and mostly it makes it difficult to distinguish between exam identification. This method therefore needs some extra effort (addition of other methods) to be complete.

[0048] Another possible cause of connection detection between the parent device and the child device can be the selection of the medical procedure. Another parent child communication is about procedures changes. The way the child answers is that it will do some internal settings if it recognizes the procedure. If it does not recognize the procedure a logline will state this. A unique feature about procedure selection is that it can be triggered from child to reach a parent. That means we can start connecting the log lines from child to the parent. But this is (child to parent) rare incidence, making it not a convenient logline / message for interconnection identification.

[0049] Another possible cause of connection detection between the parent device and the child device can be the selection of the application. Application selection usually starts from parent and goes to a child. An application might have procedure selections which may be performed without needing / involving a child. This may be misleading as usually there is no separate logline stating if the child is rightfully non-involved or the child is broken. This makes it rather un-reliable log line section to identify interconnection.

[0050] Another possible cause of connection detection between the parent device and the child device can be a “run tag / CWIS Code Method.” This method is based on unique set of characters that are used to identify a set of communications and thus being able to find a distinct set of log lines that can indicate the inter connection between parent and child. The problem is that sometimes these run tags or code identifiers are not mentioned in the parent log line. As a result, it proves to be a reliable but not a self-sufficient method to locate the inter connection between parent and child.

[0051] As explained previously, each of the five causes have their own merits and pitfalls. A combination of these methods can be used to identify the connection between parent and child loglines. In a first example, child-based exam runs (i.e., example IWS runs) are identified to find the time difference between runs tl, t2, etc. Next, IWS based runs in parent are identified to find the time difference between the runs Tl, T2, etc. Run patterns (i.e., time based) of the child are matched with patterns of Main system / parent over a period of one month. A minimum of two such pattern matches between child and parent confirms the run and response logline and these loglines can be picked as the inter-connection location.

[0052] The following rules are used in order to synchronize the logs between IWS and IXR devices. The Timestamp of the following two IWS log messages is extracted as <IWS_Timestamp>: Message A: EventID = T23456Import’ and Description starts with ‘New EPX selected', Message B: EventID = T23456789123’ and Description starts with ‘ i Assets. Infra.Domain. Xray Modality . Cwi sDvlp . Orchestrator :S end V ali dati onResultT oXray Sy stem'

[0053] For the above messages, the timestamp <Extracted_Timestamp> contained in their descriptions is also extracted. For Message A, the timestamp is contained after ‘id=. ’ For Message B, the timestamp is contained after ‘Epx=’

[0054] The timestamps of the IWS log messages are updated using the difference <rWS_Timestamp>-<Extracted_Timestamp>. In case multiple time differences detected within a day, a smallest difference is used.

[0055] The IWS messages <Message A> and <Message B> can be initiated by the IXR messages with EventIDs (procedure and application selection). {'123456789', '987654321', '192837465', '12HJIRD9876543','45JFBMR45678962'}. The timestamps of these messages in the IXR logs are extracted and compared with the IWS timestamps of <Message A> and <Message B>. If there is a larger difference than 10 minutes, the full log of the day is discarded.

[0056] Log messages from IWS and IXR logs are used when they are both operational. When in one of the two logs we detect a shutdown initiation process, messages from both sides are filtered.

[0057] In the above time-sync processes one can observe that there are several parameters / choices that are made. For example, Method B, step 5 states that “ If there is largerdifference than 10 minutes, we discard the full log of the day." . This parameter as well as the other parameters of the time-sync process are optimized with machine learning methods using past customer calls that have reported intercommunication issues between their IGT devices.

[0058] The machine learning process can include using customer calls that have reported intercommunication issues and collecting data prior to the customer call and after the intercommunication issue has been resolved. Data prior to the customer call should contain message patterns that are associated with the reported issue and data after the call should be clean of such patterns. These data can guide to the correct parameter choice because for example error messages that appear after the issue has been resolved may be explained because one of the other connected devices is simply switched off. This information / context can help us identify the correct time-sync parameters. The machine learning model 34 uses different configurations of the timesync parameters and finally select the ones that optimize model performance.

[0059] A sub-optimal time-sync parameter may wrongly indicate that both devices are switched on and thus trigger a false alert. This will be captured as a false positive prediction and thus degrade the performance of a machine learning model 34.

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

Claims

CLAIMS:

1. A non-transitory computer readable medium (16) storing instructions readable and executable by an electronic processor (14) to perform a predictive maintenance method (100), the predictive maintenance method comprising: 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 medical devices of the plurality of medical devices with a context representing an expected intercommunication between the two or more medical devices during the medical procedure; detecting one or more intercommunication errors between two or more medical devices of the plurality of medical devices based on the comparing; and outputting an alert (36) identifying the one or more intercommunication errors.

2. The non-transitory computer readable medium (16) of claim 1, wherein the method (100) further comprises: synchronizing the log data (30) of the plurality of medical devices (12) in time, wherein the detecting is performed on the log data after the synchronization.

3. The non-transitory computer readable medium (16) of claim 2, wherein the synchronizing includes: identifying timestamped events in the log data (30) of the two or more medical devices (12) corresponding with events during the medical procedure having known time synchronization; and adjusting time stamps of the log data of at least one of the two or more medical devices based on a comparison between the time stamps of the timestamped events and the known time synchronization.

4. The non-transitory computer readable medium (16) of any one of claims 1-3, wherein the method (100) further comprises: prior to the detecting, adjusting a format or structure of the log data (30) of at least one medical device of the plurality of medical devices (12) to match a format or structure of another medical device of the plurality of medical devices.

5. The non-transitory computer readable medium (16) of any one of claims 1-4, wherein the comparing of the portions of the log data (30) of the two or more medical devices (12) with the context includes: comparing events in the portions of the log data to the context comprising an expected sequence of events that is expected to occur during the medical procedure.

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

7. The non-transitory computer readable medium (16) of claim 6, wherein the method (100) further comprises: tuning one or more parameters of the one or more diagnostic rules (32) based on historical log data generated by past instances of the medical procedure; wherein the one or more diagnostic rules with the tuned one or more parameters are applied to the portions of the log data (30).

8. The non-transitory computer readable medium (16) of claim 7, wherein the tuning of the one or more parameters of the diagnostic rules (32) includes: applying a machine-learning (ML) model (34) trained on the historical log data to tune the one or more parameters of the diagnostic rules.

9. The non-transitory computer readable medium (16) of any one of claims 1-8, wherein the method (100) further comprises:determining a malfunction of one medical device of the plurality of medical devices (12) based on the detected one or more intercommunication errors; wherein the output alert (36) associates the one or more intercommunication errors with the determined malfunction of the one medical device.

10. The non-transitory computer readable medium (16) of claim 9, wherein the malfunction of the one medical device is determined by inputting the portions of the log data of the two or more medical devices to a machine learning (ML) component (34) trained on historical log data generated by past instances of the medical procedure to identify a root cause of the one or more intercommunication errors.

11. The non-transitory computer readable medium (16) of any one of claims 1-10, wherein outputting the alert (34) comprises: displaying, on a display device (24), the alert.

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

13. A non-transitory computer readable medium (16) storing instructions readable and executable by an electronic processor (14) to perform a predictive maintenance method (100), the predictive maintenance method comprising: retrieving log data (30) of events of a plurality of medical devices (12) generated during a medical procedure employing the plurality of medical devices; applying one or more diagnostic rules (32) to portions of the log data of two or more medical devices of the plurality of medical devices using a context representing an expected intercommunication between the two or more medical devices during the medical procedure; detecting one or more intercommunication errors between two or more medical devices of the plurality of medical devices based on the comparing; and outputting an alert (36) identifying the one or more intercommunication errors.

14. The non-transitory computer readable medium (16) of claim 13, wherein the method (100) further comprises: synchronizing the log data (30) of the plurality of medical devices (12) in time, wherein the detecting is performed on the log data after the synchronization.

15. The non-transitory computer readable medium (16) of claim 14, wherein the synchronizing includes: identifying timestamped events in the log data (30) of the two or more medical devices (12) corresponding with events during the medical procedure having known time synchronization; and adjusting time stamps of the log data of at least one of the two or more medical devices based on a comparison between the time stamps of the timestamped events and the known time synchronization.

16. The non-transitory computer readable medium (16) of any one of claims 13-15, wherein the method (100) further comprises: prior to the detecting, adjusting a format or structure of the log data (30) of at least one medical device of the plurality of medical devices (12) to match a format or structure of another medical device of the plurality of medical devices.

17. The non-transitory computer readable medium (16) of any one of claims 13-16, wherein the method (100) further comprises: tuning one or more parameters of the one or more diagnostic rules (32) based on historical log data generated by past instances of the medical procedure; wherein the one or more diagnostic rules with the tuned one or more parameters are applied to the portions of the log data (30).

18. The non-transitory computer readable medium (16) of claim 17, wherein the tuning of the one or more parameters of the diagnostic rules (32) includes: applying a machine-learning (ML) model (34) trained on the historical log data totune the one or more parameters of the diagnostic rules.

19. The non-transitory computer readable medium (16) of any one of claims 13-18, wherein the method (100) further comprises: determining a malfunction of one medical device of the plurality of medical devices (12) based on the detected one or more intercommunication errors; wherein the output alert (36) associates the one or more intercommunication errors with the determined malfunction of the one medical device.

20. A predictive maintenance method (100), comprising: retrieving log data (30) of events of a plurality of medical devices (12) generated during a medical procedure employing the plurality of medical devices; identifying timestamped events in the log data (30) of the two or more medical devices (12) corresponding with events during the medical procedure having known time synchronization; adjusting time stamps of the log data of at least one of the two or more medical devices based on a comparison between the time stamps of the timestamped events and the known time synchronization; comparing portions of the log data of two or more medical devices of the plurality of medical devices with a context representing an expected intercommunication between the two or more medical devices during the medical procedure; detecting one or more intercommunication errors between two or more medical devices of the plurality of medical devices based on the comparing; and outputting an alert (36) identifying the one or more intercommunication errors.

Images