Intelligent automated fmeca

Abstract

A system and method include acquisition of technical service descriptions associated with a type of medical imaging system, identification of cause entities and action entities in the technical service descriptions, determination of cause clusters comprising respective ones of the cause entities and action clusters of comprising respective ones of the action entities, determination of failure clusters from the cause clusters, prompting of a text generation model to determine names for each failure cluster, cause cluster and action cluster, determination of associations between the named failure clusters, cause clusters and action clusters based on the technical service descriptions, and, for each failure cluster, determination of a cost based on costs of the cause clusters associated with the failure cluster.

Description

Docket No. 2024P16480WOINTELLIGENT AUTOMATED FMECA BACKGROUND

[0001] Medical equipment manufacturers are subject to stringent guidelines regarding equipment efficacy. Certification authorities require detailed data which demonstrates that the requirements are met, and which explains the data collection processes and assumptions behind the data. Common approaches for generating this data include Failure Mode and Effects Analysis (FMEA) and Failure Mode, Effects and Criticality Analysis (FMECA). These approaches are bottom-up analytical methods for identifying potential failure modes at a component, sub-system, system level or processes and determining the downstream effects thereof.

[0002] FMEA, FMECA and other conventional approaches initially involve manual brainstorming among experts to identify potential failures and effects thereof. For each failure, a value from 1-10 is assigned to each of the following failure characteristics: severity, likelihood of occurrence, and likelihood of detection. A Risk Priority Number (RPN) for each failure is determined based on its three assigned values (e.g., RPN = severity x likelihood of occurrence x likelihood of detection).

[0003] The outcome of these approaches strongly depends on human knowledge and individual expertise in the respective field. Even assuming a high level of expertise, the values of each of the failure characteristics and resulting RPN are quite subjective and cannot be strictly relied upon. Moreover, these approaches are manual and exponentially timeconsuming with increasing system complexity.

[0004] For large and complex machines such as medical imaging systems, it is impractical to assess all possible combinations of failures. Analysis is therefore typically restricted to predominant component and sub-system failures. Not only are other system failures ignored, but conventional approaches also tend to ignore failures due to external factors such as environmental fluctuations, user errors, power instability and process (e.g., quality assurance, calibration) failures. Conventional failure analysis also fails to adequately relate failures with critical factors such as the resulting cost to the manufacturer or customer.Docket No. 2024P16480WO

[0005] Hence there is a need for systems to efficiently and automatically identify possible failures, their causes and associated costs thereof in a complex medical imaging system.BRIEF DESCRIPTION OF THE DRAWINGS

[0006] FIG. 1 illustrates an automated FMECA system according to some embodiments.

[0007] FIG. 2 illustrates an example failure, cause and action hierarchy generated according to some embodiments.

[0008] FIG. 3 is a flow diagram of a process for automated FMECA according to some embodiments.

[0009] FIG. 4 depicts text of a technical service description according to some embodiments.

[0010] FIG. 5 illustrates training of a named entity recognition model according to some embodiments.

[0011] FIG. 6 illustrates unsupervised training of a clustering model to generate cause clusters according to some embodiments.

[0012] FIG. 7 illustrates unsupervised training of a clustering model to generate action clusters according to some embodiments.

[0013] FIG. 8 illustrates unsupervised training of a clustering model to generate failure clusters according to some embodiments.

[0014] FIG. 9 is a view of a user interface depicting costs associated with failures and causes according to some embodiments.DETAILED DESCRIPTION

[0015] The following description is provided to enable any person in the art to make and use the described embodiments. Various modifications, however, will be readily-apparent to those in the art.Docket No. 2024P16480WO

[0016] Embodiments provide a large language model-based architecture for automated failure mode analysis. Failure mode analysis according to some embodiments may be applied to any products or systems of any industry. In the examples below, the failure mode analysis is described in the context of medical imaging systems, such as but not limited to Positron Emission Tomography (PET) scanners, Single-Photon Emission Computed Tomography (SPECT) scanners, Computed Tomography (CT) scanners, and Magnetic Resonance (MR) scanners.

[0017] FIG. 1 illustrates an automated FMECA system according to some embodiments. Embodiments are not limited to the FIG. 1 architecture. Generally, the FIG. 1 architecture implements a system to acquire technical service descriptions (e.g., service tickets) which are typically generated by service technicians during maintenance and other servicing of medical imaging systems. Based on the text of the technical service descriptions, a hierarchy of failure types, their respective causes, and respective corrective actions are determined.Moreover, the technical service descriptions are used to determine costs for each failure and for each cause in view of the actions which resolve the failure / cause. These costs are key metrics for quantifying the impact of a failure and are not readily generated using conventional approaches.

[0018] Embodiments advantageously perform FMECA based on technical service descriptions which are created in the field for other purposes. The descriptions may be associated with multiple types (i.e., models) of imaging systems and various software versions. The technical service descriptions may include multiple languages and cover a wide range of failures and issues experienced by customers across the world. The failures and issues may vary based on environmental conditions, machine usage, user behavior and multiple other factors.

[0019] The acquired technical service descriptions are stored in repository 110. The technical service descriptions may be transmitted by and / or pulled from multiple sources over any desired period of time. The technical service descriptions themselves may describe maintenance, repair or other services performed over any time period. Repository 110 may comprise any type of data storage system that is or becomes known. Repository 110 mayDocket No. 2024P16480WOcomprise a vector database system for generating and storing multi-dimensional vectors representing each acquired technical service description, for example.

[0020] FIG. 1 illustrates several potential sources of technical service descriptions according to some embodiments. Embodiments are not limited to the depicted sources. Medical imaging scanner 120a may comprise a PET scanner, a PET / CT scanner, or any type of medical imaging system that is or becomes known. Technician 122a may comprise one or more personnel charged with maintaining, repairing, or otherwise ensuring proper operation of scanner 120a. Technician 122a may operate device 124a (e.g., a tablet computer, a dedicated diagnostic device, a mobile phone) to create technical service description (i.e., a service ticket) 125a and to provide description 125a to repository 110. Although one description 125a is depicted, technician 122a may operate device 124a to create any number of technical service descriptions which are associated with scanner 120a or with other scanners.

[0021] Technical service description 125a may describe technical symptoms or issues exhibited by scanner 120a, causes thereof, and corrective actions taken to address the technical symptoms or issues. The technical symptoms or issues may include but are not limited to poor image quality, component malfunctions leading to poor image quality, system start-up issues, calibration problems, system overheating and non-functioning components. The corrective actions may include but are not limited to site visits, installation of replacement parts, and troubleshooting.

[0022] Device 120b may comprise a laptop computer or a desktop computer used to generate technical service description 125b and provide description 125b to repository 110. Device 120b is intended to illustrate that a technical service description need not be generated by an on-site technician but may be generated remote from the medical imaging system which the technical service description concerns. Such a technical service description may be generated after an on-site or a remote diagnosis and servicing of the medical imaging system. The medical imaging system may be scanner 120a or another scanner of the same make and model as scanner 120a.Docket No. 2024P16480WO

[0023] Medical imaging scanner 120c may comprise the same type of scanner as scanner 120a. As described above, technician 122c may operate device 124c to create technical service description 125c and to provide description 125c to repository 110. Finally, repository 120d may store previously-generated technical service descriptions and provide batch of descriptions 125d to repository 110 on demand.

[0024] Entity recognition network 130 receives the technical service descriptions stored in repository 110 and identifies cause entities and action entities which may be present in each of the technical service descriptions. In some embodiments, the technical service descriptions are translated using a translation model (not shown) prior to input to network 130. The translation may translate all non-English text in the technical service descriptions to English. One or more other target languages may be used, for example, the predominant language of the technical service descriptions.

[0025] Entity recognition network 130 may comprise a network to perform Named Entity Recognition (NER) as is known in the art. NER is a technique for extracting information from unstructured text. Generally, NER classifies text into pre-defined categories. The categories may be established by customizing a generic entity recognition model based on sample text data in which the categories (i.e., entities) to be recognized are pre-labeled. The sample text data may be limited to a particular domain (e.g., medical imaging).

[0026] The text is tokenized and normalized for input to a model to be customized. The model may consist of a BiLSTM-CRF (Bidirectional Long Short-Term Memory with Conditional Random Fields) model, a transformer-based model (e g., BERT, RoBERT a), etc. The selected model may be customized via transfer learning or by defining a custom output layer (e.g., a classification layer) corresponding to the desired entities. The customized model (e.g., network 130) is serialized into a format (e.g., PyTorch, TensorFlow) which can be deployed for use as shown in FIG. 1. Network 130 and networks 133, 135, 150 and 180 may be deployed, for example, on servers and accessed via RESTful APIs, on cloud services in which a network is loaded into a function and invoked via HTTP requests, in containers deployed in desired environments, or via cloud deployment platforms to which a network is uploaded and which expose an endpoint for interacting with the model.Docket No. 2024P16480WO

[0027] Network 130 and networks 133, 135, 150 and 180 and prompt generator 170 may be implemented using any suitable combination of local, on-premise, cloud-based, distributed computing hardware (e.g., including distributed storage and / or compute nodes) and / or software that is or becomes known. A cloud-based implementation of any elements of FIG. 1 may apportion computing resources elastically according to demand, need, price, and / or any other metric. Each element described herein may be executed by an execution environment including one or more physical and / or virtualized servers, clusters of a container orchestration system, etc. Such an execution environment may provide an operating system, services, I / O, storage, libraries, frameworks, etc. to applications executing therein.

[0028] In response to the input technical service descriptions, entity recognition network 130 outputs text portions 132 which are identified as cause entities and text portions 134 which are identified as action entities. For example, given the following text of a technical service description input to entity recognition network 130: “ring artifact showing in some patients, cleaned detector and plexi ring, ran defective channels, no bad channels shown, ran phantom, no indication of artifact, system is operational.”, network 130 may identify “ring artifact showing in some patients” as a cause entity 132 and “cleaned detector and plexi ring” as an action entity 134.

[0029] Clustering network 133 clusters text portions 132 into cause clusters 142. Each cause cluster 142a and 142b of cause clusters 142 includes text portions of text portions 132 which are semantically similar to one another and semantically dissimilar to the text portions of other cause clusters. In one example, cluster 142a includes text portions "Detector 2 not initializing”, “Detector init failure. AIMD error.”, “Detector initialization error”, and “Detectors initial error - self test”, while cluster 142b includes text portions “computer will not communicate with the camera”, “Communication error between snac and detector”, “Error while communicating with detector”, and “keeps losing connection to camera”.Similarly, clustering network 135 clusters text portions 134 into action clusters 144, and each action cluster 144a and 144b includes text portions of text portions 134 which are semantically similar to one another and semantically dissimilar to the text portions of other action clusters.Docket No. 2024P16480WO

[0030] Clustering networks 133 and 135 may comprise autoencoders, recurrent neural networks and / or transformer models. Clustering networks 133 and 135 may be customized by adding layers to project the input data into a lower-dimensional latent space, to optimize cluster assignments directly during training and / or to introduce trainable parameters for cluster centers, allowing the network to optimize the parameters j ointly with feature learning.

[0031] Clustering networks 133 and 135 may implement text clustering algorithms as are known in the art. The algorithms may comprise, but are not limited to, K-Means clustering, DBSCAN clustering, hierarchical clustering, topic modeling and spectral clustering.Algorithm parameters such as the number of clusters, distance metric, and minimum cluster size may be specified by a developer. The algorithms may use any suitable similarity metric (e.g., semantic similarity).

[0032] Clustering network 150 may comprise a network such as networks 133 and 135. Clustering network 150 clusters text portions of cause clusters 142 into failure clusters 160. For example, each failure cluster 162a and 162b may include text portions of one or more cause clusters of clusters 142 and which are semantically similar to one another. According to some embodiments, two different ones of failure clusters 160 do not include text portions of the same one of cause clusters 142. That is, each cause cluster 142 is associated with only one of failure clusters 160.

[0033] Prompt generator 170 prompts text generation model 180 to determine names for each failure cluster of clusters 160, each cause cluster of clusters 142 and each action cluster of clusters 144. Prompt generator 170 may generate a prompt (e.g., consisting of a system prompt and a user prompt) which includes the text portions of each cluster and instructions for generating names for each cluster based on the corresponding text portions. The instructions may be included within a prompt template which prompt generator 170 populates with the text portions. Model 180 outputs X failure names 192, Y cause names 194 and Z action names 196.

[0034] Text generation model 180 may comprise a neural network trained to generate text based on input text. Embodiments may implement a generative model which generates any type of data based on an input prompt, including but not limited to image, video and audioDocket No. 2024P16480WOdata. According to some embodiments, model 180 is a Large Language Model (LLM) conforming to a transformer architecture. Non-exhaustive examples of an LLM include GPT-4, LaMDA, Claude or the like. A transformer architecture may include, for example, embedding layers, feedforward layers, recurrent layers, and attention layers. An embedding layer creates embeddings from input text, intended to capture the semantic and syntactic meaning of the input text. A feedforward layer is composed of multiple fully-connected layers that transform the embeddings. Some feedforward layers are designed to generate representations of the intent of the text input. A recurrent layer interprets the tokens (e.g., words) of the input text in sequence to capture the relationships between the tokens.Attention layers may employ self-attention mechanisms which are capable of considering different parts of input text and / or the entire context of the input text to generate output text. Generally, each layer includes nodes which are connected to the input of nodes of a subsequent layer to form a directed and weighted graph. Each node receives input, changes its internal state according to that input, and produces an output depending on the input and internal state.

[0035] FIG. 2 illustrates hierarchy 200 of failure, cause and action names. Hierarchy 200 was generated based on technical service descriptions associated with a particular type of imaging device (i.e., PET312A). Hierarchy 200 depicts associations between various ones of the failure, cause and action names. For each failure name, embodiments may identify an associated failure cluster and the cause clusters which are included in the failure cluster. The names of the included cause clusters are then associated with the failure name. For each cause name, the text portions of the corresponding cause cluster are identified. Next, action clusters are identified which include text portions which were present in the same technical service descriptions as the text portions of the corresponding cause cluster, and the names of the identified action clusters are associated with cause name.

[0036] Hierarchy 200 is a portion of a larger hierarchy of names generated as described above. For example, although only failure name “PET QC Failed” is associated with causes, each other depicted failure name may be associated with one or more causes. Similarly, although hierarchy 200 associates only cause name “PET_QC_348 Full Setup Failed” withDocket No. 2024P16480WOactions, each other depicted cause name may be associated with one or more actions.Hierarchy 200 may include many more failures, causes and actions than shown in FIG. 2.

[0037] FIG. 3 comprises a flow diagram of process 300 to perform automated FMECA according to some embodiments. Process 300 and the other processes described herein may be performed using any suitable combination of hardware and software. Software program code embodying these processes may be stored by any non-transitory tangible medium, including a fixed disk, a volatile or non-volatile random-access memory, a DVD, a Flash drive, or a magnetic tape, and executed by any number of processing units, including but not limited to processors, processor cores, and processor threads. Such processors, processor cores, and processor threads may be implemented by a virtual machine provisioned in a cloud-based architecture. Embodiments are not limited to the examples described below.

[0038] Initially, at S310, a plurality of technical service descriptions associated with a type of medical imaging system are acquired. The technical service descriptions may be acquired from a central repository and / or may be received over time until a suitable number of descriptions have been acquired. The technical service descriptions may comprise service tickets which are generated by technicians in the usual course of their workday. The acquired technical service descriptions may be associated with a particular type of medical imaging system for which a FMECA is desired.

[0039] FIG. 4 depicts technical service description 400 acquired at S310 according to some embodiments. Technical service description 400 includes text describing an issue, troubleshooting activities and actions taken to resolve the issue. Description 400 also includes a number of hours worked, a number of site visits associated with the issue, a measure of system downtime, and a list of replaced parts. This text may be used as described below to determine costs associated with failures. Embodiments are not limited to the information provided by description 400.

[0040] At S320, entity recognition is performed to identify cause entities and action entities within the technical service descriptions. The technical service descriptions may be translated into a common language prior to the entity recognition. The output of S320 consists of text portions which are labeled as cause entities or action entities.Docket No. 2024P16480WO

[0041] FIG. 5 illustrates customizing of generic NER model 510 according to some embodiments. NER training component 520 customizes NER model 510 based on text portions 530 and their associated entity labels 535 as is known in the art. Text portions 530 may be associated with the medical imaging domain and labels 535 may specify either “cause” or “action”. Customizing results in entity recognition network 540 which may be used to perform entity recognition at S320.

[0042] Clustering is performed at S330 to determine clusters of cause entities and clusters of action entities. FIG. 6 illustrates determination of clusters of cause entities according to some embodiments of S330. Unsupervised training component 620 inputs identified cause entities 132 into clustering network 610 and, until predetermined clustering criteria (e g., number of clusters, distance between clusters, minimum similarity of cluster elements) are satisfied, receives output clusters from network 610, modifies network 610, and re-inputs cause entities 132. Clustering network 610 may implement any clustering algorithm conforming to any suitable parameters. Satisfaction of the clustering criteria results in cause clusters 142 and trained cause entity clustering network 630. Trained network 630 may be used in future iterations of S330, eliminating the need for unsupervised training of clustering network 610 during the future iterations.

[0043] FIG. 7 illustrates determination of clusters of action entities according to some embodiments of S33O. Unsupervised training component 620 inputs identified action entities 134 into clustering network 710, receives output clusters from network 710, modifies network 710, and repeats these steps until clustering is deemed complete. Clustering network 710 may be identical to or different from clustering network 610. Clustering of the action entities results in action clusters 144 and trained action entity clustering network 740. Trained network 740 may also be used in future iterations of S330 to determine clusters of action entities as described with respect to trained network 630.

[0044] Next, at S340, clustering is performed to determine clusters of failure entities from the clusters of cause entities determined at S330. As illustrated in FIG. 8, unsupervised training component 620 inputs cause entity clusters 144 into clustering network 810 and trains network 810 to cluster the text portions of entity clusters 144 into failure clusters 160, which also results in trained network 820. Unsupervised training component 620 mayDocket No. 2024P16480WOcontrol the clustering such that different clusters of failure clusters 160 do not include text portions of the same cause cluster.

[0045] A text generation model is prompted at S350 to determine names for each failure cluster, cause cluster and action cluster. For each cluster, the prompt may list all of the text portions of the cluster and request a name summarizing the text portions. The prompt may instruct the model that the name summarizing the text portions of a failure cluster should be a name of a failure, the name summarizing the text portions of a cause cluster should be a name of a cause, and the name summarizing the text portions of an action cluster should be a name of an action.

[0046] At S360, associations are determined between the named clusters based on the technical service descriptions. As described above with respect to hierarchy 200, S360 may include identifying, for each failure cluster, the cause clusters whose text portions are included in the failure cluster. The names of the identified cause clusters are then associated with the name of the failure cluster. For each cause cluster, the action clusters whose text portions were present in the same technical service descriptions as the text portions of the cause cluster are identified, and the names of the identified action clusters are associated with name of the cause cluster.

[0047] A cost is determined for each failure cluster at S370. The cost for a failure cluster may be determined based on the costs of the cause clusters associated with the failure cluster. With reference to hierarchy 200, failure cluster “PET QC Failed” is associated with cause clusters “PET QC 352 Phantom”, “PET QC 328 Failed Blocks”, “Sinogram with Artifact”, “Time Alignment Failed”, “PET QC 348 Full Setup Failed”, “ACS Checkup Failed”, and “Miscellaneous”. Accordingly, the cost associated with failure cluster “PET QC Failed” is the sum of the costs associated with each of these cause clusters.

[0048] The determination of a cost associated with a cause cluster may include identifying all of the acquired technical service descriptions which include a cause entity of the cause cluster and summing the costs associated with each thusly-identified technical service description. The costs of a technical service description according to some embodiments may include a parts replacement cost, a servicing cost and a customer dissatisfaction cost.Docket No. 2024P16480WOThe parts replacement cost is the cost of all replacement parts described in the technical service description. The servicing cost may be determined based on a number of working hours specified in the technical service description and an hourly labor cost (i.e., working hours x hourly labor cost), and on a travel cost determined based on the number of site visits mentioned in the technical service description. The customer dissatisfaction cost may be calculated based on a period of system downtime mentioned in the technical service description. For example, a monetary cost may be associated with each hour of downtime, and the monetary cost per hour may increase as the number of hours of downtime increases to reflect increasing levels of customer dissatisfaction. The cost associated with a cause cluster is not limited to the above factors.

[0049] Advantageously, the determined costs are a useful and previously-unavailable metric for impact assessment of multiple failure modes and the prioritization thereof.Moreover, the costs may be used to quantify improvements which were made in view of prior failure mode analysis (e.g., costs prior to FMECA vs. costs after FMECA).

[0050] FIG. 9 is a view of a user interface depicting costs which were determined to be associated with cause clusters according to some embodiments and as described above. Column 910 lists the names of the failure clusters determined at S350. The failure cluster name “UPS” has been expanded and column 920 lists the names of the cause clusters which are associated with the “UPS” failure cluster and which were determined at S350. Column 930 indicates the number of site visits mentioned in the technical service descriptions associated with each listed failure cluster and cause cluster, column 940 indicates the average number of site visits listed in these technical service descriptions, and column 950 indicates the number of technical service descriptions associated with each listed failure cluster and cause cluster.

[0051] The total costs determined at S370 for each cause cluster are broken out into their replacement parts costs, service costs, and customer dissatisfaction costs in columns 960, 970 and 990, respectively. The number of hours of downtime, which are used to determine the customer dissatisfaction costs in some embodiments, is provided in column 980.Embodiments are not limited to the presentation of the determined costs depicted in FIG. 9.Docket No. 2024P16480WO

[0052] Automated determination of these costs as described above may result in a significant improvement to traditional FMECA. Particular benefits may be enjoyed when executing FMECA of a new product which is an incremental change from an existing product for which many historical service tickets are available. The FMECA of the new product may leverage clusters and associated costs determined from the historical service tickets as described above.

[0053] The foregoing diagrams represent logical architectures for describing processes according to some embodiments, and actual implementations may include more, or different components arranged in other manners. Other topologies may be used in conjunction with other embodiments. Moreover, each component or device described herein may be implemented by any number of devices in communication via any number of other public and / or private networks. Two or more of such computing devices may be located remote from one another and may communicate with one another via any known manner of network(s) and / or a dedicated connection. Each component or device may comprise any number of hardware and / or software elements suitable to provide the functions described herein as well as any other functions. For example, any computing device used in an implementation of a system according to some embodiments may include a processor to execute program code such that the computing device operates as described herein.

[0054] All systems and processes discussed herein may be embodied in program code stored on one or more non-transitory computer-readable recording media. Such media may include, for example, a hard disk, a DVD-ROM, a Flash drive, magnetic tape, and solid-state Random Access Memory (RAM) or Read Only Memory (ROM) storage units.Embodiments are therefore not limited to any specific combination of hardware and software.

[0055] Embodiments described herein are solely for the purpose of illustration. Those in the art will recognize other embodiments may be practiced with modifications and alterations to that described above.

Claims

Docket No. 2024P16480WOWHAT IS CLAIMED IS:

1. A method comprising:acquiring a plurality of technical service descriptions associated with a type of medical imaging system;performing entity recognition to identify cause entities and action entities in the plurality of technical service descriptions;determining cause clusters comprising respective ones of the cause entities and action clusters of comprising respective ones of the action entities;determining failure clusters from the cause clusters;prompting a text generation model to determine names for each failure cluster, cause cluster and action cluster;determining associations between the named failure clusters, cause clusters and action clusters based on the technical service descriptions; andfor each failure cluster, determining a cost based on costs of the cause clusters associated with the failure cluster.

2. The method of Claim 1, wherein determining the cost for each failure cluster comprises determining, for each failure cluster, a cost of each cause entity of the technical service descriptions of the cause clusters which are associated with the failure cluster.

3. The method of Claim 2, wherein the cost of a cause entity includes a service visit cost, a replacement parts cost, and a customer dissatisfaction cost.Docket No. 2024P16480WO4. The method of Claim 1, wherein the cost of a failure cluster includes a service visit cost, a replacement parts cost, and a customer dissatisfaction cost.

5. The method of Claim 1, wherein each failure cluster is associated with one or more cause clusters and each cause cluster is associated with one or more action clusters.

6. The method of Claim 5, wherein an action cluster is associated with two or more cause clusters.

7. The method of Claim 6, wherein determining the cost for each failure cluster comprises:for each failure cluster:determining an associated one or more cause clusters; anddetermining the cost based on the technical service descriptions associated with each of the one or more cause clusters.

8. The method of Claim 7, further comprising determining a cost for each cause cluster based on the technical service descriptions associated with each of the one or more action clusters associated with the cause cluster.

9. The method of Claim 8, wherein the cost of a failure cluster and the cost of a cause cluster includes a service visit cost, a replacement parts cost, and a customer dissatisfaction cost.Docket No. 2024P16480WO10. A system comprising:a memory storing executable program code; andat least one processing unit to execute the program code to cause the system to perform operations comprising:acquiring a plurality of technical service descriptions associated with a type of medical imaging system;performing entity recognition to identify cause entities and action entities in the plurality of technical service descriptions;determining cause clusters comprising respective ones of the cause entities and action clusters of comprising respective ones of the action entities;determining failure clusters from the cause clusters;prompting a text generation model to determine names for each failure cluster, cause cluster and action cluster;determining associations between the named failure clusters, cause clusters and action clusters based on the technical service descriptions; andfor each failure cluster, determining a cost based on costs of the cause clusters associated with the failure cluster.

11. The system of Claim 10, wherein determining the cost for each failure cluster comprises determining, for each failure cluster, a cost of each cause entity of the technical service descriptions of the cause clusters which are associated with the failure cluster.Docket No. 2024P16480WO12. The system of Claim 11, wherein the cost of a cause entity includes a service visit cost, a replacement parts cost, and a customer dissatisfaction cost.

13. The system of Claim 10, wherein the cost of a failure cluster includes a service visit cost, a replacement parts cost, and a customer dissatisfaction cost.

14. The system of Claim 10, wherein each failure cluster is associated with one or more cause clusters and each cause cluster is associated with one or more action clusters.

15. The system of Claim 14, wherein an action cluster is associated with two or more cause clusters.

16. The system of Claim 15, wherein determining the cost for each failure cluster comprises:for each failure cluster:determining an associated one or more cause clusters; anddetermining the cost based on the technical service descriptions associated with each of the one or more action clusters associated with the associated one or more cause clusters.

17. The system of Claim 16, the operations further comprising determining a cost for each cause cluster based on the technical service descriptions associated with each of the one or more cause clusters.Docket No. 2024P16480WO18. The system of Claim 17, wherein the cost of a failure cluster and the cost of a cause cluster includes a service visit cost, a replacement parts cost, and a customer dissatisfaction cost.

19. One or more non-transitory computer-readable media storing program code, the program code executable by at least one processing unit of a computing system to cause the computing system to perform operations comprising:acquiring a plurality of technical service descriptions associated with a type of medical imaging system;performing entity recognition to identify cause entities and action entities in the plurality of technical service descriptions;determining cause clusters comprising respective ones of the cause entities and action clusters of comprising respective ones of the action entities;determining failure clusters from the cause clusters;prompting a text generation model to determine names for each failure cluster, cause cluster and action cluster;determining associations between the named failure clusters, cause clusters and action clusters based on the technical service descriptions; andfor each failure cluster, determining a cost based on costs of the cause clusters associated with the failure cluster.

20. The one or more non-transitory computer-readable media of Claim 19, wherein determining the cost for each failure cluster comprises determining, for each failure cluster, a cost of each cause entity of the technical service descriptions of the cause clusters which are associated with the failure cluster.

Images