Patent Description:
A medical imaging system may occasionally malfunction. In such situations, a service case is created, which captures all maintenance activities carried out to diagnose and resolve the issue. A malfunction area of the service case is defined as the subcomponent or functional subsystem of the medical imaging system which failed to work as. It is used both for diagnostic purposes, as well as for reliability analysis.

Typically, the list of possible malfunction areas is created and maintained by domain experts. In some approaches, the malfunction areas can be determined based on a particular maintenance activity performed during the service case. Each maintenance activity is manually assigned to a malfunction area, and a malfunction area of the service case is determined by applying fixed rules to the set of (maintenance activities, malfunction area) pairs. An example of such an approach is to determine a malfunction area of the service case based on the replaced parts in the service case. For that approach, a mapping between parts and malfunction areas is maintained. An example of a rule for determining a malfunction area of the service case is to use the functional subsystem of the most expensive replaced part.

In other examples, the malfunction areas can be determined based on pre-defined text patterns/regular expressions for service actions, which are mapped to malfunction areas. An example of such an approach would be to assign malfunction areas to error codes found in machine logs. Then, if an error code appears anywhere in a service case (e.g. in the log data, or in engineering notes), the appropriate malfunction area is used for the service case.

Both approaches require significant effort from experts to maintain the mapping between maintenance activities (e.g. based on replaced parts) or patterns (e.g. based on encountered error codes) and malfunction areas. For instance, for one Magnetic Resonance Imaging (MRI) scanner design, more than <NUM>,<NUM> different parts are in use, and more than <NUM>,<NUM> unique three-word combinations are found in engineering notes in historical service cases (word combinations that appear in at least <NUM>% and at most in <NUM>% in the cases). Manually processing and maintaining such a list is a labor-intensive operation. Furthermore, it is often not clear which malfunction area should be assigned to a part since the same part may be used for resolving different issues (e.g. replacement kits).

Furthermore, both approaches identify a malfunction area retrospectively. This is because the part replaced, or the service action entries, are not available in complete form until after the service case is closed.

The following discloses certain improvements to overcome these problems and others.

A document <CIT> discloses a parts co-replacement recommendation system for field servicing of medical imaging systems. At a service device, a user interface is provided via which a user submits an order request to order a requested part via the at least one user input device. Co-replacement information for the requested partis identified using a co-replacements database, and is displayed on the display. For example, a second part commonly co-replaced with requested part may be identified and recommended for replacement with part; or, if two parts and are ordered then the co-replacement information may be to recommend ordering only one of these parts. At a server hosting the database, the order request is received from a service device and the co-replacement information for the requested part is generated using the co-replacements database, and the co-replacement information is sent to the service device.

In one aspect of the invention, a non-transitory computer readable medium is defined in claim <NUM>.

In another aspect of the invention, an apparatus for automated identification of one or more malfunction areas of a set of malfunction areas for a service case in which a medical device is serviced is defined in claim <NUM>.

In another aspect of the invention, a method of automated identification of one or more malfunction areas of a set of malfunction areas for a service case in which a medical device is serviced is defined in claim <NUM>.

One advantage resides in reducing downtime of a medical imaging device.

Another advantage resides in automatically identifying one or more proposed malfunction areas of a medical device based on interaction of the service technician with existing systems such as a parts ordering user interface and/or a service report entry user interface.

Another advantage resides in generating patterns from historical cases to determine potential malfunction areas of a medical device.

Another advantage resides in providing one or more proposed malfunction areas during execution of a service call, thereby providing this information in real time for consideration by the service technician in deciding how to perform the servicing.

Another advantage resides in recommending repair actions for one or more potential malfunction areas of a medical device.

A given embodiment may provide other advantages as will become apparent to one of ordinary skill in the art upon reading and understanding the present disclosure.

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.

Current methods of servicing medical devices include identifying a malfunction area associated with each service call. By way of non-limiting illustrative example, one medical imaging device manufacturer currently defines <NUM> malfunction areas for a magnetic resonance imaging (MRI) scanner, including, for example: RF coils, patient support, RF (amplifiers et cetera), gradient coils, image quality, data acquisition and so forth. A given malfunction may fit into multiple malfunction areas, for example a problem with an RF coil may impact the RF coils, image quality, and data acquisition malfunction areas. In such an "overlapping" case, the usual practice is to assign a single most relevant malfunction area for the case. (in this example, the "RF coils" malfunction area would most likely be assigned as the problem directly relates to the RF coils).

Presently, a malfunction area is assigned to a service case retrospectively, that is, at or after closing the case. A malfunction area may be assigned automatically based on the major replaced part, or manually by the service technician. For the former approach, malfunction areas are assigned to replacement parts during MRI system design, or the first time the part is replaced and the service engineer assigns a malfunction area to that part then thereafter the same malfunction area is assigned to that part.

However, there are some difficulties with this approach. It may not be apparent which is the "major part" that was replaced in a service call. For example, the service engineer may replace a low-cost part to solve the actual malfunction, but during the service call may also perform preventive maintenance involving replacing a higher-cost part, thereby creating a misassignment of a malfunction area based on the higher-cost part that was not implicated in the actual malfunction.

Furthermore, the assignment of malfunction area retrospectively has the disadvantage of not providing the service engineer with real-time information. Knowing the (most likely) malfunction area during servicing could be useful information for the service engineer.

In view of the foregoing, the following discloses an approach for dynamic likely malfunction area assignment. In the illustrative examples, two data sources are mined: the part descriptions of replaced parts and written notes including the malfunction report and notes generated by the service engineer during the servicing. However, it is contemplated to use only one of these data sources. Conversely, other sources are also contemplated to be mined, such as machine logs. The illustrative example creates and utilizes three classifiers for determining the probable malfunction area(s), as follows.

A first classifier receives as input a bag-of-words representation of the parts descriptions for the part or parts ordered for replacement, and outputs a (first) vector of probabilities of the malfunction areas based on those parts descriptions. For example, if MRI has <NUM> malfunction areas then the output vector has <NUM> elements corresponding to the respective malfunction areas. If the first vector element corresponds to the 'RF coils' malfunction area then the value of the first vector element stores the probability that a malfunction area for the service case is 'RF coils'; if the second vector element corresponds to the patient support malfunction area then the value of the second vector element stores the probability that a malfunction area for the service case is patient support; and so forth.

A second classifier receives as input a bag-of-words representation of the malfunction report and service engineer notes and operates similarly to the first classifier to output a second vector of probabilities of the malfunction areas, with this vector being based on the text description of the service case.

The first and second classifiers can be any text classifier, such as, by way of non-limiting illustrative example, a support vector machine (SVM) classifier.

A third classifier combines the outputs of the first and second classifiers. Hence, the third classifier receives the first and second vectors of probabilities output by the first and second classifiers, and outputs a vector of probabilities of the malfunction areas. The third classifier can employ averaging, majority voting, linear regression, decision trees, or other approaches for combining the results.

The three classifiers are trained on a training set of historical service cases that have already been annotated by experts with malfunction area.

The trained classifiers may be used as follows. The service engineer accesses the usual service case application via which the service engineer receives the malfunction report, interfaces with a parts ordering system to order parts, enters the service engineer notes, and may engage in other activities such as bringing up and following a root cause isolation flowchart or decision tree or utilize other diagnostic tools. A malfunction area module as disclosed herein is also included in the service case application. This module runs in the background, and receives the malfunction report, parts descriptions of ordered parts (such a part description is automatically provided by the parts ordering user interface when the user selects a part for order), and entered service engineer notes in real time. As these activities are received, the textual information (e.g. textual part descriptions and textual service engineer notes) is extracted and run through the appropriate classifiers to generate a ranked list of most likely malfunction areas. As these are fast operations, the output of any classifier and hence the ranked list is updated in (near) real-time. A window of the service case application displays the most likely malfunction area, or in a preferred approach, a "top-N" most likely malfunction areas. The use of a specific classifier is dependent on the status of the problem resolution. If the service engineer has not resolved the problem, then the list of ordered part is empty, and the first and third classifiers cannot be run. Therefore, in this case, only the second classifier is used to produce a ranked list of most likely malfunction areas. This list can be used by the service engineer to guide him during root cause analysis. If the service engineer has resolved the problem, then the output of all three classifiers is considered, and the output from the third classifier (i.e. the combined vector of probabilities of the malfunction areas) is used to produce a ranked list of most likely malfunction areas.

While described in the context of MRI in the illustrative examples, the approach is also suitably used for servicing of any imaging modality, such as X-ray, Computed Tomography (CT), Positron Emission Tomography (PET), Single Photon Emission Computed tomography (SPECT), Ultrasound, and so forth. In addition, the approach can be used for other medical devices, such as patient monitors.

With reference to <FIG>, an apparatus or system <NUM> for automated identification of one or more malfunction areas of a set S of malfunction areas for a service case in which a medical device <NUM> is serviced is shown. As shown in <FIG>, a service engineer SE, who is servicing a medical imaging device (also referred to as an image acquisition device, imaging device, and so forth) <NUM>, is located in a medical imaging device bay <NUM>, and a server computer <NUM> is disposed in a remote service location or center <NUM>. The remote location <NUM> is typically a site owned or leased or otherwise controlled by the imaging device vendor or other imaging device service provider.

A single image acquisition device <NUM> is shown by way of illustration, which can be a Magnetic Resonance (MR) image acquisition device, a Computed Tomography (CT) image acquisition device; a positron emission tomography (PET) image acquisition device; a single photon emission computed tomography (SPECT) image acquisition device; an X-ray image acquisition device; an ultrasound (US) image acquisition device; or a medical imaging device of another modality. The imaging device <NUM> may also be a hybrid imaging device such as a PET/CT or SPECT/CT imaging system. While a single image acquisition device <NUM> is shown by way of illustration in <FIG>, more typically the service location or center <NUM> will provide monitoring and maintenance servicing for a fleet of imaging devices, e.g. for all or a subset of medical imaging devices sold by the vendor under service contracts between the customers (e.g., owner or operator of the imaging bays <NUM>).

In a typical scenario, the imaging device <NUM> automatically generates machine logs that record operational information pertaining to the imaging devices <NUM>, such as scans performed, hardware and parameters used in the scans, device configuration changes, and so forth. These logs can be automatically transferred to the service center <NUM> by way of the communication link <NUM>, such as the Internet possibly augmented by local area networks at the customer end <NUM> and/or at the service center end <NUM>. These logs may for example be transferred on a daily basis or more or less frequently.

<FIG> also shows the service engineer SE operating a service device <NUM>, which comprises an electronic processing device such as a smartphone, a tablet, a laptop computer, or more generally a computer. The service device <NUM> includes typical components, such as an electronic processor <NUM> (e.g., a microprocessor), at least one user input device (e.g., a mouse, a keyboard, a trackball, a touch screen, and/or the like) <NUM>, and at least one display device <NUM> (e.g. an LCD display, plasma display, cathode ray tube display, and/or so forth). The electronic processor <NUM> is operatively connected with a one or more non-transitory storage media <NUM>. The non-transitory storage media <NUM> 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 service device <NUM>, various combinations thereof, or so forth. It is to be understood that any reference to a non-transitory medium or media <NUM> herein is to be broadly construed as encompassing a single medium or multiple media of the same or different types. Likewise, the electronic processor <NUM> may be embodied as a single electronic processor or as two or more electronic processors. The non-transitory storage media <NUM> stores instructions executable by the at least one electronic processor <NUM>. The instructions include instructions to generate a graphical user interface (GUI) <NUM> for display on the service device display device <NUM>.

The disclosed communication link <NUM> includes the server computer <NUM> (or a cluster of servers, cloud computing resource comprising servers, or so forth) which is programmed to establish connections between the server computer and the service engineer SE.

The server computer <NUM> is operatively connected with a one or more non-transitory storage media <NUM>. The non-transitory storage media <NUM> 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 server computer <NUM>, various combinations thereof, or so forth. It is to be understood that any reference to a non-transitory medium or media <NUM> herein is to be broadly construed as encompassing a single medium or multiple media of the same or different types. Likewise, the server computer <NUM> may be embodied as a single electronic processor or as two or more electronic processors. The non-transitory storage media <NUM> stores instructions executable by the server computer <NUM>.

Furthermore, as disclosed herein the server computer <NUM> performs a method or process <NUM> for automated identification of one or more malfunction areas of a set S of potential malfunction areas for a service case in which the medical device <NUM> is serviced. The set S of potential malfunction areas can be stored in the non-transitory storage media <NUM> of the server computer. The non-transitory storage media <NUM> also stores instructions for the server computer <NUM> to perform the method <NUM>.

With reference to <FIG>, and with continuing reference to <FIG>, the method <NUM> is shown as an exemplary flow chart. In some examples, the method <NUM> may be performed at least in part by cloud processing. To begin the method <NUM>, the service engineer SE begins a service case to service the medical device <NUM> and logs on to the service device <NUM> to connect the service device <NUM> to the server computer <NUM> via the communication link <NUM>.

At an operation <NUM>, a parts ordering user interface <NUM> for ordering parts for the service case is provided on the GUI <NUM> of the service device <NUM>. The parts ordering user interface <NUM> provides text descriptions of the parts ordered for the service case. The service engineer SE can order a part via the user input device <NUM> (e.g., by tapping on the screen of the service device <NUM>, or with mouse clicks or keyboard strokes via a mouse of keyboard comprising the at least one user input device). When this occurs, the parts ordering user interface <NUM> retrieves a text description of the ordered part from a first database <NUM> of the non-transitory computer readable medium <NUM> of the server computer <NUM>. The parts ordering user interface <NUM> provides for ordering parts for the service case from a parts inventory, which can include, for example, at least <NUM> parts. In some examples, none of the text descriptions of the at least <NUM> parts of the parts inventory include annotations indicating malfunction areas associated to the parts.

The server computer <NUM> also includes a malfunction area module <NUM> that is also included in the service case application. The malfunction area module <NUM> runs in the background, and receives the malfunction report, parts descriptions of ordered parts (such a part description is automatically provided by the parts ordering user interface <NUM> when the user selects a part for order), and entered service engineer notes in real time.

At an operation <NUM> performed by the malfunction area module <NUM>, the ordered part is detected, and the corresponding part description is extracted. This can be done using a suitable application programming interface (API) or other hook enabling the malfunction area module to receive this information. The extracted part description is preferably converted to a standardized format suitable for input to a text classifier. For example, the part description can be converted to a bag-of-words representation, optionally with other processing such as removing frequent and uninformative "stop" words (e.g., "and", "the", et cetera).

At an operation <NUM> (which may in general be performed before, after, or concurrently with, operation <NUM>), a service report entry user interface <NUM> for receiving a text description of the service case is provided on the GUI <NUM> of the service device <NUM>. The service report entry user interface <NUM> can include at least a malfunction report for the medical device <NUM> and repair notes for the service case. This malfunction report would typically be entered by an imaging technician or other user of the MRI <NUM> and would typically have been uploaded to the server computer <NUM> and subsequently downloaded to the service device <NUM> when the SE opened the service case. The service engineer SE can input repair notes via the user input device <NUM> (e.g., by tapping on the screen of the service device <NUM>, or with mouse clicks or keyboard strokes via a mouse of keyboard comprising the at least one user input device), and this information would also be included in the developing service report. The written notes can be stored in a second database <NUM> of the non-transitory computer readable medium <NUM> of the server computer <NUM>.

At an operation <NUM> performed by the malfunction area module <NUM>, the text content of the developing service report is extracted, preferably in (near) real-time, e.g. as the text is entered into the service report entry user interface <NUM>. This can again be done using a suitable API or other hook enabling the malfunction area module to receive this information. The extracted text is preferably converted to a standardized format suitable for input to a text classifier. For example, the text can be converted to a bag-of-words representation, optionally with other processing such as removing frequent and uninformative "stop" words (e.g., "and", "the", et cetera).

At an operation <NUM>, an output probability vector <NUM> of probabilities for the set S of malfunction areas of the medical device <NUM> is generated by operations including applying at least one classifier to at least one of (<NUM>) the text descriptions of the parts ordered for the service case and/or (<NUM>) the text description of the service case. The vector generation operation <NUM> can be performed in a variety of manners.

In some embodiments, the vector generation operation <NUM> includes applying a first classifier <NUM> to the text descriptions of the parts ordered for the service case. To do so, the first classifier <NUM> can mine the first database <NUM> to find the text descriptions for the service case. From the retrieved data, the first classifier <NUM> is programmed to output a first probability vector <NUM> for the set S of malfunction areas of the medical device <NUM>.

In other embodiments, the vector generation operation <NUM> includes applying a second classifier <NUM> to the to the text description of the service case. To do so, the second classifier <NUM> can mine the second database <NUM> to find the to the text descriptions for the service case. From the retrieved data, the second classifier <NUM> is programmed to output a second probability vector <NUM> for the set S of malfunction areas of the medical device <NUM>.

In further embodiments, the first probability vector <NUM> and the second probability vector <NUM> are both generated, and then are combined to generate the output probability vector <NUM> of probabilities for the set S of malfunction areas of the medical device <NUM>. In some examples, the first classifier <NUM> and/or the second classifier <NUM> can be a support vector machine (SVM) classifier.

In still further embodiments, the medical device <NUM> can store log files <NUM> in a non-transitory computer readable medium <NUM> of the medical device. The log files <NUM> can be automatically maintained and can be transmitted to the server computer <NUM> and stored in a third database <NUM>. A third classifier <NUM> can mine the third database <NUM> to find the log files <NUM> and generate a third probability vector <NUM> therefrom. The output probability vector <NUM> can be generated from a combination of the first probability vector <NUM>, the second probability vector <NUM>, and the third probability vector <NUM>. Although not utilized in the illustrative examples, it is contemplated for such machine log data to be mined as a third data source. In such embodiments, the third classifier <NUM> comprises an additional text-based classifier would ingest the machine log text and output a vector of probabilities for the set S of malfunction areas of the medical device <NUM>. This could then be combined by the third classifier along with the illustrative first and second vectors of <NUM>, <NUM> probabilities output by the illustrative first and second text classifiers <NUM>, <NUM>. The additional use of the machine log data would be expected to provide (even) more accurate probable malfunction areas.

At an operation <NUM>, a list <NUM> of one or more most probable malfunction areas for the service case is displayed on the display device <NUM> of the service device <NUM>. The one or more most probable malfunction areas are the one or more malfunction areas of the set S of malfunction areas having highest probability in the output probability vector <NUM>. In some examples, the list <NUM> can comprise a top "N" number of malfunction areas can be included in the list. It is also contemplated for the list to have only a single most probable malfunction area (equivalent to a top-N list where N=<NUM>). In another approach, the number of listed malfunction areas is not preset, but rather each malfunction area whose probability exceeds some predefined threshold (e.g. probability of <NUM> or higher) is included in the list.

As noted, the output probability vector <NUM> represents of probabilities for the set S of malfunction areas of the medical device <NUM>. Each probability of probabilities of the one or more malfunction areas of the medical device <NUM> can correspond to a corresponding potential malfunction of the medical device The set S of malfunction areas a single malfunction area of the medical device <NUM>; however, the output probability vector <NUM> is representative of the entire set S of malfunction areas, so that the service engineer SE can select one of the malfunction areas from the set of malfunction areas.

In some embodiments, the displaying operation <NUM> can include receiving a selection of a user-identified malfunction area for the service case via the user input device <NUM> interacting with the displayed list <NUM>. For example, the service engineer SE can select a malfunction area on the display device <NUM> with a finger tap or with mouse clicks or keyboard strokes via a mouse of keyboard comprising the at least one user input device). The selected user-identified malfunction area can be automatically added to the text description of the service case.

In some embodiments, the generating operation <NUM> of the output probability vector <NUM> and the displaying operation <NUM> of the list <NUM> are repeated iteratively (for example, each time one of the extraction operations <NUM>, <NUM>) detects new information in the form of a newly ordered part with corresponding part description per operation <NUM> or text added to the developing service call report per operation <NUM>) to update the list in real-time as the parts ordering user interface <NUM> receives orders for parts for the service case and/or the service report entry user interface <NUM> receives updated repair notes for the service case.

At an operation <NUM>, the service engineer SE can select a final determination of the malfunction areas, which is then included in the report. The report can be stored in the non-transitory computer readable medium <NUM> of the server computer <NUM>. In some examples, a recommended repair action for the service case can be displayed on the display device <NUM>.

The following describes in more detail the algorithms of the method <NUM>. The method <NUM> aims to make the process of identifying malfunction areas more efficient, by using the apparatus <NUM> for automatic identification of the malfunction areas for new service cases. The databases <NUM>, <NUM>, <NUM> are built by learning patterns from historical service cases, which have already been annotated with the appropriate malfunction areas. The maintenance activities in each service case are treated as textual fields, and the words and sequences of words (e.g. three-word combinations) in each activity are used as initial features. Then, several text classifiers <NUM>, <NUM>, <NUM> are built, focusing on particular maintenance activities (e.g. using only descriptions of replaced parts as features), or on all activities in a service case. The output probability vector <NUM> of all these classifiers <NUM>, <NUM>, <NUM> may be combined (i.e. used as features for a subsequent classifier), to give a more precise prediction of the malfunctioning area of each service case.

These learned patterns do not have to be reviewed by an expert. Typically, the expert is required for occasional quality control of the automated system. This significantly reduces their workload, as a small fraction of the new service cases would need to be inspected.

Furthermore, the method <NUM> can be used to classify both closed service cases and open service cases, which are still being handled by the service engineer SE. In the former case, the apparatus <NUM> can use all recorded activities in a service case to determine the malfunction areas. In the latter case, since the service case is ongoing, only a subset of the maintenance activities has been completed and registered. The apparatus <NUM> would use only this information and can produce the list <NUM> of likely malfunction areas. The service engineer SE can use this list <NUM> to narrow down the problem area and identify the root-cause more efficiently (Figure <NUM>). The service engineer SE can use the apparatus <NUM> multiple times during the handling of a service case (e.g. after each diagnostic step has been performed), to produce an updated list <NUM> of likely malfunction areas.

The part description data in the first database <NUM> can be used to train the first classifier <NUM>, and the data in the second database <NUM> can be used to train the second classifier <NUM>. The third classifier <NUM> can be trained on predictions from the first and second classifiers <NUM>, <NUM>.

The first and second classifiers <NUM> and <NUM> can have a typical text classification structure, consisting of a pre-processing stage (e.g., input tokenization, removal of punctuation symbols etc.), vectorization stage, where tokens (e.g., words) are mapped to an m-dimensional vector space (e.g., TF-IDF, word2vec, etc.), and a machine learning-based classification stage (e.g., support vector machines). The output of each classifier <NUM> and <NUM> is an array of values between zero and one, with exactly one value assigned for each possible malfunction area. The lower (higher) the score the lesser (more) likely it is the maintenance case belongs to the corresponding malfunction area where values <NUM> and <NUM> are the lowest and highest possible values.

The third classifier <NUM> is programmed to combine the first and second classifiers <NUM> and <NUM> trained on different activity types. The third classifier <NUM>, also known as stacked classifier, uses the predictions of the first classifier <NUM> and the second classifier <NUM> as input features (i.e., the scores per classifier per malfunction area), and has the same output type as the first classifier <NUM> and the second classifier <NUM>. The implementation of the third classifier <NUM> can vary from simple (e.g., averaging, majority voting, and so forth) to more complex machine learning approach (e.g., linear regression, decision tree, and so forth).

In an example, the method <NUM> was used for a MR medical device <NUM>. In MR, a malfunction area of a service case is determined based on the malfunction area of the most expensive part. The example focused on a set of <NUM>,<NUM> corrective maintenance cases from two countries, where <NUM>,<NUM> unique parts were replaced.

As noted, the first classifier <NUM> is generated for replacement parts of the medical device <NUM>, and the second classifier <NUM> is generated for service cases to classify the malfunction area(s). Both classifiers <NUM>, <NUM> have the same architecture, but are trained separately, do not share any internal state, and may learn different patterns.

Both classifiers <NUM>, <NUM> can be trained and tested on the set of service cases/parts with a known malfunction area. To do so, a disjoint training/test split of the unique most expensive parts can be performed with <NUM>% of parts in the training set, and <NUM>% of the test set. This set was used for training and testing the second classifier <NUM>. For creating the training and test set for the first classifier <NUM>, services cases were assigned to the training/test set based on the assignment of their most expensive part in the first set.

For the final list <NUM>, the output vectors <NUM>, <NUM> from the first and second classifiers <NUM>, <NUM> can be combined. In some examples, the third output vector <NUM> can be combined with the output vectors <NUM>, <NUM>. The third classifier <NUM> can use, for example, a Logistic Regression process, as shown in the graph of <FIG>.

Claim 1:
A non-transitory computer readable medium (<NUM>) storing instructions executable by at least one electronic processor (<NUM>) to perform a method (<NUM>) of automated identification of one or more malfunction areas of a set (S) of malfunction areas for a service case in which a medical device (<NUM>) is serviced, the method comprising:
providing a parts ordering user interface (<NUM>) for ordering parts for the service case, the parts ordering user interface providing text descriptions of the parts ordered for the service case;
providing a service report entry user interface (<NUM>) for receiving a text description of the service case including at least a malfunction report for the medical device and repair notes for the service case;
generating an output probability vector (<NUM>) of probabilities for the set of malfunction areas of the medical device by operations including applying at least one classifier (<NUM>, <NUM>) to at least one of (<NUM>) the text descriptions of the parts ordered for the service case and/or (<NUM>) the text description of the service case; and
displaying a list (<NUM>) of one or more most probable malfunction areas for the service case wherein the one or more most probable malfunction areas are the one or more malfunction areas of the set of malfunction areas having highest probability in the output probability vector; and
wherein the generating of the output probability vector (<NUM>) includes:
generating a first probability vector (<NUM>) of probabilities for the set (S) of malfunction areas of the medical device (<NUM>) by applying a first classifier (<NUM>) to the text descriptions of the parts ordered for the service case;
characterized by
generating a second probability vector (<NUM>) of probabilities for the set of malfunction areas of the medical device by applying a second classifier (<NUM>) to the text description of the service case; and
combining the first probability vector and the second probability vector to generate the output probability vector of probabilities of the one or more malfunction areas of the medical device.