JP2006505335A - Automated medical imaging system maintenance diagnosis - Google Patents

Abstract

The medical imaging system diagnostic package includes the ability to analyze operator usage data to detect aspects of how the system is used that may be responsible for operational problems. Detection of problems due to the manner in which the system is used can reduce the number of “no problems found” repair calls and can be permanently solved by additional operator training in the use of the system. The diagnostic package includes the ability to assess the effects of software aging by analyzing the status of components of medical systems used by software such as registers, memory and disk drives. The results of this analysis can be used to improve degraded software performance that does not completely fail, such as system slowdown and increased response time.

Description

  The present invention relates to medical diagnostic imaging systems, and more particularly to medical diagnostic imaging systems that can be automatically maintained to prevent system failure.

  Medical imaging systems, including modalities such as MRI, CT, nuclear imaging and ultrasound, are a major investment for hospitals, clinics and medical research institutions. Thus, facilities that own these systems usually try to fully utilize them. System failures and failures interrupt the workflow of these systems and reduce their use. For this reason, most manufacturers strive to provide effective scheduled maintenance routines and responsive repair services. Regular maintenance of these systems must detect them before potential failures occur, and in the event of a failure, repair services must quickly identify and resolve the problem. It must be done.

  Regular maintenance procedures for imaging systems generally pay attention to the operability and status of the system's own components, modules, software and other components. Factors such as voltage, temperature and performance speed are characteristics of system components that can be measured and analyzed in routine maintenance procedures, and the results are used to predict evolving problems. However, system users often report problems with systems that routine maintenance is unpredictable or unpredictable. Components or modules are frequently replaced by repair personnel and returned to the repair facility, where no problem with the part is found. In many such examples, the problem is not due to a failure of the system itself, but to the incorrect use of the system or the results it generates. Therefore, it is desirable for a scheduled maintenance procedure to identify issues regarding how the system is used in addition to potential failures of system components.

  In accordance with the principles of the present invention, a medical imaging system diagnostic package includes the ability to analyze operator usage data to detect aspects of the manner in which the system is used that may be the cause of operational problems. Detecting problems due to the manner in which the system is used can reduce the number of “no problems found” repairs, often solved permanently by additional operator training in the use of the system Can be done.

  According to another aspect of the invention, a medical imaging system diagnostic package includes the ability to monitor and analyze system characteristics that represent software aging. Software aging is not a hard (tight) system failure, but can cause system problems that degrade system performance such as performance slowdowns and runtime error messages and crashes. According to another aspect of the invention, the maintenance system identifies software aging problems and presents the user with procedures for addressing the software aging problems.

  Referring first to FIG. 1, an ultrasound diagnostic imaging system constructed in accordance with the principles of the present invention is shown in block diagram form. At the top of the figure is a probe 10 having an array transducer 12 that transmits and receives ultrasound signals in a two-dimensional or three-dimensional imaging field, and processes the signals from the elements of the array transducer to form a coherent echo signal. A beamformer 14, an ultrasound signal processor 16 that processes the echo signal, for example by filtering, detection, Doppler processing or other processes, an image processor 18 that processes the signal into a display format, and an ultrasound image or data is displayed. There is a signal path of a typical ultrasound system having a display 20 that is connected. The operation of these components is coordinated by the system controller 22. The operation of the ultrasound system is directed by a user controller 62 that is coupled to the system controller. The system controller 22 can store images and diagnostic reports in the storage device 24. The system controller further accesses an ultrasound diagnostic (application) 28 for performing diagnostic maintenance and repair (repair) of the ultrasound system, as described in more detail below.

  The ultrasound system has a plurality of devices for data storage and communication such as the hard disk drive 40 shown in FIG. 2, for example, and other devices such as a magneto-optical disk, a CD-R drive and / or a floppy disk drive. Peripheral devices can also be included. Some or all of the capacity for image and report storage 24 and ultrasound diagnostic (application) 28 storage may be provided by these devices. The ultrasound system can receive information from an external source through the server 30 or transmit information to the external source. The server communicates through the protocol stack 46. The protocol stack 46 shows some of the more universal communication protocols that can be used. Above the stack 46 are application protocols for host sessions, file transfers, email, web applications and network monitoring. The next level in the stack is Telnet, FTP, SMTP, HTTP and SNMP presentation protocols. The third layer has TCP and UDP protocols, and the next layer has IP protocols. In the fifth layer, there are PPP and Ethernet protocols, and in the lower layer of the stack, there is a physical layer connected to an external communication device. Several communication devices, including a serial port 31, a modem 32, and a network (Ethernet) connection 36 are shown in the embodiment of FIG. This array of communication protocols and devices allows the ultrasound system to connect directly to other devices through a proprietary or public point-to-point network, by telephone line and / or through the Internet and the World Wide Web. .

  FIG. 2 shows a portion of the ultrasound system of FIG. 1 in more detail. The system controller 22 includes a computer motherboard 50 having a CPU 52 and a random access memory (RAM) 54. The CPU executes preventive maintenance (PM) and repair diagnosis application stored in the disk drive 40. The CPU further executes other applications that run on the ultrasound system. In FIG. 2, some of the diagnostic application programs and data files stored in the disk drive 40 are listed under the heading ultrasound diagnosis. Ultrasound diagnostic applications include expert maintenance applications that perform preventive maintenance (PM), expert repair applications that run inference engines and use logic rules and facts, such as error logs, user interface logs, monitor logs, service logs, and temperatures System logs including files such as / voltage logs. These programs and applications are described in more detail below. Motherboard 50 further operates web server 30 connected to video card 58 and network card 56 in a preferred embodiment. The video card allows the web server to display web pages on the system display 20. The video card can also be used in embodiments configured to display diagnostic images and information generated by the image processor 18 on the display 20. The network card allows the web server to remotely access through the network 115 as indicated by the remote diagnostic device 110 to the ultrasound system as described in US patent application Ser. No. 09 / 534,143. It enables communication with service centers 120 as may be operated by service personnel performing or by the manufacturer of the ultrasound system. By connecting the web server to both the network card and the video card, the remote service person can see the same screen display as the display 20 that the imaging system operator is viewing.

  In accordance with the first aspect of the invention, the ultrasound diagnosis (application) includes a preventive maintenance system referred to herein as an expert maintenance application. The expert maintenance application is preferably present in the ultrasound machine and is executed when the ultrasound machine enters diagnostic mode. The expert maintenance application is automated and can be initiated by an operator of the ultrasound system, a field repair person, a repair person with remote access, or a repair center with remote access as shown in FIG. The expert maintenance application can also be initiated by the imaging system itself during off-hour self-maintenance. The expert maintenance application analyzes system parameters according to a set of rules. Some of the rules may be defined by the user as described below. In a configured embodiment, the expert maintenance application analyzes the ultrasound system and reports reminders on non-critical issues or alerts on issues that may cause system failure. The maintenance analysis report is presented to the user so that the user can select which reminders and alerts to resolve, as shown in FIG.

  According to another aspect of the invention, preventive maintenance applies to both hardware and software components. Hardware maintenance is defined as an activity that is regularly performed on physical devices to prevent developing problems from becoming a bottleneck. Examples of such maintenance include replacing overheating components, cleaning corroded electrical contacts, or returning loose electrical connections to the correct position. Techniques for detecting these types of problems are well known and include monitoring of temperature sensors, electrical impedance and applied voltage and require no further explanation. The monitored parameters are recorded by the expert maintenance application and presented to the user in the report. The severity of the situation is indicated to the user (reminder, alert, warning) and the user or machine can take appropriate action.

  On the other hand, software maintenance is defined as a periodic activity performed on the software to reduce or eliminate the effects of software aging. This can be contrasted with software crashes such as software crashes or software that does not run or runs properly. All of these software failures are “hard” failures, many of which require serviceman action to repair or replace defective software. Software aging can lead to software failures, and software maintenance aims to prevent such failures. Software aging can be detected by identifying the effects of software aging. Examples of software aging effects are memory leaks, unreleased file locks, data compaction, storage space fragmentation, and accumulation of rounding errors that can cause poor system performance or ultimately system failure. Examples of responses to these detected situations are as simple as restarting an ultrasound machine, more complicated like system disk drive defragmentation, or the same as replacing old software or adding system resources It can be as complex. Software aging can affect the diagnostic capabilities of the system by causing more downtime, degraded system performance, or reduced system reliability if it is left unaccounted.

  The expert maintenance application can analyze many operating parameters of the software that are retrieved in real time or observed in the machine log and report the results of this analysis to the user for recommended operation. Some of the parameters analyzed in the configured embodiment include the following:

  A. The expert maintenance application analyzes the number of temporary (temporary) files (* .tmp) created before the system was last booted. This number can be compared to the desired maximum number of temporary files set by the user.

  B. The expert maintenance application analyzes the number of backup files (* .bak) created before the system was last booted. This number can be compared to the desired maximum number of backup files set by the user.

  C. The expert maintenance application analyzes the number of saved lost files (* .chk) created during the previous scan disk process. This number can be compared to the desired maximum number of lost files set by the user.

  D. The expert maintenance application analyzes the total number of web browser history files. This number can be compared to the desired maximum number of history files set by the user.

  E. The expert maintenance application records the free storage area of the hard disk from the operating system and alerts the user if the free space falls below a given size, such as 10% of the total disk size.

  F. The expert maintenance application analyzes hard disk fragmentation and alerts the user when file fragmentation exceeds a predetermined amount, eg, 10%.

  G. The expert maintenance application analyzes the number of committed bytes to determine if the number of committed bytes exceeds the amount of physical RAM.

  H. The expert maintenance application analyzes the number of page reads per second to determine if the system is loading more programs into virtual memory than can be handled efficiently.

  I. The expert maintenance application analyzes the total bytes received per second on the system network to see if the number exceeds the steady level and indicates excessive utilization of system bandwidth.

  J. et al. The expert maintenance application analyzes the disk access time and alerts the user if the disk access time exceeds a certain percentage.

  These are just a few of the possible techniques for detecting software aging. None of these situations show immediate system failure, but each of them shows a developing situation that can lead to problems or perceived problems. One problem that can be perceived by the system operator is that the system is operating more slowly than before. This is not a hard (tight) failure, but it can lead to service calls, but in many cases is a problem that can be solved by expert maintenance applications. FIG. 3 illustrates the detection of factors that are causing or can lead to perceived system slowdown situations. FIG. 3 shows a general report displayed on the display screen at the end of execution of the expert maintenance application. The window on the left side of the screen can be examined by an expert maintenance application that includes a series of system modules, an ultrasound machine front-end controller (FEC), and multiple ultrasound probes (C5-2, C8-4v, etc.). Indicates a module that can. The upper right window shows the result of regular maintenance, and it can be seen that this example shows software aging. The severity of the situation is shown on the left side of the window (warning, alert), and a button that allows the situation to be resolved is shown on the right side of each situation. For example, if the user clicks the “Fix It” button to the right of the temporary file warning at the top of the window, the system will automatically create a temporary file created prior to the most recent system startup. Delete it. Most of the solutions displayed in this window reduce the consumption of system resources that may contribute to or gradually toward a system slowdown situation and avoid the need for service calls to address the problem be able to. In some cases, a permanent solution can be achieved by an increase in resources such as more RAM or larger disk drives, but in many cases the situation is the system operator at the end of the preventive maintenance procedure. It is only temporary that can be improved by.

  If the user wants more information about the result, the user highlights the result as indicated by box 60. In this case, the lower window displays more detailed information about the nature of the situation and advises the user about problems that may arise if the situation is not resolved. Recommendations are also shown in this window.

  According to another aspect of the present invention, ultrasound diagnostics (applications) analyze system usage data to solve problems. Usage data analysis can be used during preventive maintenance procedures or during repair procedures. Hard (tight) system failures are relatively easy to detect and problems such as system slowdown are relatively more difficult to detect. On the other hand, certain problems are not caused at all by a system failure, but by the manner in which the system is used. Many such problems are identified and addressed through analysis of system usage data. This data can take many forms and can be in a variety of different locations of the ultrasound system. In the configured embodiment, the usage data is present in the system log and error log stored in the disk drive 40. 4 and 5 show two displays of system usage data as a function of time. The windows on the left side of FIGS. 4 and 5 show a plurality of system logs that are generally maintained in the ultrasound system. The right window of FIG. 4 shows a scatter plot of usage data over a two month period, and the bottom window identifies the usage data used in the scatter plot. In this example, error events in the error log are plotted as a function of the time (time zone) at which they occurred over a two month period. The scatter diagram shows the error events actually recorded every day between 7 am and 8 am. These are potentially situations that were recorded when the ultrasound system was activated every morning. Similarly, there is a fairly even appearance of daily events between 1900 and 2100 hours, possibly due to scheduled maintenance being performed automatically every evening off hour. However, irregular groups of events (clusters) can also be seen in the scatter plot. For example, there is a group of events that appeared between 12 noon and 14:24 on the week of April 13 (4/13/2002). This concentrated occurrence (clustering) prompts to investigate what the ultrasonic machine was doing at that time and day. The survey is, for example, what type of test was performed, what mode of operation was used, and who was operating the system at that time.

  The usage information can also be expressed in the form of a bar graph as shown in FIG. 5, in which a trend can be observed. This graph shows the number of error events that appear each week over a two month period. These results, for example, prompt questions such as: The question, for example, what was the use of the ultrasound system during the week of February 9 when the incident was highest, March 23 when the incident was lowest From what was the use of the ultrasound system during the period of April 12th.

  Machine data trends and pattern identification can be visually observed and identified by humans through machine diagnostic reports, or this knowledge can be encoded into the machine repair / maintenance system . In a repair / maintenance system, trends and patterns can be automatically identified as they are identified by humans or within similar factors that are user definable.

  The answers to the questions prompted by these representations of usage data are often related to problems and errors that occur if the ultrasound machine is not used properly. The answer often suggests use by operators who have inadequate system training or little system experience. Instead of just making a service call that would result in a “no problem found” for the machine, such a problem could be solved by providing increased training to the sonographer operating the ultrasound machine. There are many cases.

  This response not only benefits the engine and manufacturer by reducing service calls, but can also help the engine become more skilled and more competitive. For example, the clinic can send its usage data to the manufacturer's service center, where the usage data can be compared to the usage data of other system owners. Usage data from one clinic may show a much higher level of error events than data from a similar clinic conducting similar tests throughout town, across the country, or across the globe. As a result, the service center can assist the clinic in examining its workflow and system usage compared to other institutions. Through increased training and / or process improvements, the clinic can improve its efficiency and system utilization, and consequently improve the level of service and health care provided by the clinic.

  In accordance with another aspect of the principles of the present invention, the diagnostic package questions the user and provides interactive guidance that provides guidance that allows the user to solve ultrasound system problems without serviceman intervention. Includes system. Of course, an interactive repair system may be used by service personnel. An interactive repair system can obtain qualitative information from the user about the state of the ultrasound system. An interactive repair system can also combine this qualitative information with the quantitative information that it automatically obtains and analyzes both types of information to arrive at a recommended repair strategy. Several query screens of an example interactive repair system are shown in FIGS. 6a-6d. When the user enters an interactive repair mode, the repair system first asks about the nature of the problem as shown in FIG. 6a. The user is asked which area of the ultrasound system appears to be problematic. A plurality of choices are displayed, and the user can select from among them. In this example, the user clicks the “Ultrasound Machine” option and clicks the “Submit” button to enter his selection. If the user clicks on the selection and changes his mind, the user can click on the “Reset” button to clear the previous selection, or “Reset ( "Reset)" button can be clicked twice.

  In this example, after indicating that the problem appears to be related to the ultrasound machine, the user is asked to provide further information regarding the evidence of the problem, as shown in FIG. 6b. For example, the user is asked if the problem appears to be one of inconsistent behavior or degraded performance. These properties can be subjective. In this example, the user is looking at the error banner and selects it as an answer to submit. In response to this answer, the repair system asks the user which error banner the user has seen, as shown in FIG. 6c. Here, the user is given a pull-down list and selects from the list. The user pulls down the list and submits the appropriate banner number. In this example, when the repair system receives the banner identity, it looks for a known correlation between the chosen banner and another system operation, in this case a previous unauthorized shutdown. In FIG. 6d, the user is asked if there was an unauthorized shutdown before the error. The user can make a “Yes” or “No” selection or click “Check Logs”. Clicking on “Check Logs” prompts the repair system to automatically search the system log stored in the disk drive 40 to automatically answer questions.

  After the query is over and the repair system has acquired the necessary information, the repair system indicates its termination and recommended action policy. The information entered may not suggest a definitive repair procedure or may indicate a repair that requires service personnel. In the latter case, a recommendation is given that a service call should be made. In the example shown in FIG. 7, the repair system is not a known Digital Video Subsystem (DVS) problem, but an improper shutdown has been detected in the error log file, which is a system software problem. To conclude. The user is given a recommended course of action, which in this example is to restart the ultrasound system.

  These repair activities and their results are recorded and stored in the system disk drive 40. If the same or similar problem occurs in the future, the repair system will have this history information that forms the basis for the recommended course of action. For example, if the degraded performance problem is repeated several times in a short time frame, the repair system can conclude that more system resources are needed to support the application run by the user. A service call is recommended so that repair personnel can evaluate the need for upgraded RAM or larger disk drives for the ultrasound system, which permanently addresses the problem.

  Details of the contents and operation of the repair system of the present invention are shown in FIGS. 8a-8c, 9 and 10. FIG. FIGS. 8a-8c show a logic flow diagram of the sequence of questions and answers that are asked and received by the repair system when there is a problem with the digital video subsystem (DVS). In the configured embodiment shown in these drawings, the first sequence of questions to the left of dashed line 70 yields individual answers that directly lead to the next question. For example, an answer that an error banner has been displayed directly leads to a question of which error banner has been displayed. On the right side of the dashed line 70, the logic is more complex as answers to multiple questions are required before the next question is created, as indicated by logic gates 72-78. For example, the logical AND gate 74 is below, as it receives a “No” answer to the question on the left side of the gate and is indicated by the output of the logical OR gate 76 coupled to the input of the gate 74. An output is generated only when a “No” answer is entered in response to the other two questions.

  The outputs of logic gates 74 and 78 are coupled as inputs to the process shown in FIGS. 8b and 8c. These processes represent a series of questions and logic operations and are thus configured in accordance with another aspect of the present invention, which processes are performed by an inferencing or reasoning. The inference engine uses a backward chain (goal drive strategy) to infer a given problem, which in this example is a problem with the operation of the ultrasound system. This method relies on the assumption that the existence of the goal must be established or refuted. This strategy is enhanced by depth-first (vertical) search by backtracking. All of the rules from within the rule set are ordered on a first-come-first-served basis, and the first successful goal encountered is the goal that is reported to the user. As an alternative, the inference engine can parse and consider all possible outcomes and report a list of prioritized strategies for solving the problem.

  In the constructed embodiment, a runtime inference engine available from Amzi !, Inc. (Lebanon, Ohio, USA) was used. The inference engine utilizes facts and logic rules that are entered as user answers to questions stored on the disk drive 40 or questioned by the system. The inference engine not only looks at the answer to the previous question, but also analyzes the answers given to all previously asked questions and other facts known to the system. Thus, the inference engine applies artificial intelligence to the given information to reach termination and recommendations. This determines which questions should be asked next, and continues until all of the known and useful information available meets the set of rules that lead to a known problem and its resolution. This is done by analyzing all of the given answers and available facts. The advantages of this method include ease of implementation; rules and facts are easy to understand and communicate naturally; the results can be easily explained and derived; New facts and rules can be added regardless of the analysis program; new facts and rules can be combined with previously known facts and rules to infer new knowledge.

  FIGS. 8b and 8c illustrate the questions that the inference engine can ask the user and the conclusions that can be reached by this artificial intelligence process. Some of the recommended courses of action can be implemented by the user, such as reloading a software unit, but others such as hard disk unplugging, PCI card replacement, power supply replacement are generally , Requires expert knowledge of a technician or service person. Thus, it is clear that the inference engine can be used by a user or repairman to facilitate analysis and repair of the ultrasound system.

  FIG. 9 shows a screen on which an ultrasound system manufacturer or service technician can enter questions to be asked by the interactive repair system. A text-based programming language, such as XML or Prolog, is preferably used to program the questions, thereby making manufacturing personnel minimally familiar with the computer programming language Or it allows a repairman to create a question and enter the question. In the example where the question is shown, “DVS unit turns blue and restart?” Is entered, and the answer shown for this question is “Yes” or “No”. is there.

  FIG. 10 shows the logic rules written to guide the inference engine to the analysis of the problem. Again, text-based programming languages are preferably used for ease of programming and understanding. In this example, the programmer enters the situation that logically exists under a given situation in the left column and the conclusion reached by the inference engine for the defined situation in the right column. The inference engine may update the facts about the ultrasound system stored in the disk drive 40 and other facts and data available in the ultrasound system at some time, such as due to automated measurements. And analyze specific problems and use them with qualitative answers entered by the user and possibly recommended action policies to arrive at a logical conclusion.

  At the end of the repair procedure assisted by artificial intelligence, the results of the repair can be stored in a local knowledge database residing on the system or a network accessible to the system. These results constitute information or facts known to the repair system for performing future repair analyses. The result of the repair can also be communicated to the repair center 120 or downloaded periodically by the repair center or repair personnel and sent to the repair center. At the repair center, other repair personnel and / or ultrasound system manufacturers use these results generated by one ultrasound system when repairing other similar ultrasound systems at other locations. be able to. Furthermore, when these other systems analyze their system problems, information can be communicated to those other systems as facts to be considered by their inference engine. In addition, the information is entered into the manufacturer's database and used in the design and generation of future ultrasound systems.

  Another embodiment of the repair system of the present invention is illustrated by the display screen of FIG. This screen includes a box in the upper right that shows the results of the repair diagnosis and the recommended repair strategy. In the box on the left side of the screen is a tree of system structures that can be diagnosed and repaired by an automated repair system. The box at the bottom right of the screen shows a summary of questions asked by the system and answers entered by the user, based on which repair recommendations are based. This summary box gives the user the ability to review the answer given by the user to verify that the appropriate answer has been entered. If the user sees the answer and wants to change it, the user changes the answer and the automated repair system logically reinforces the data enhanced by this different input to reach termination and recommendation again. To analyze.

1 is a block diagram illustrating an ultrasound diagnostic imaging system constructed in accordance with the principles of the present invention. FIG. 2 is a block diagram illustrating further details of a controller and ultrasound diagnostic portion of the system of FIG. The figure which shows an example of the result of the regular maintenance diagnosis performed by the principle of this invention. The figure which shows the display of the system use data in the form of a scatter diagram. The figure which shows the display of the usage trend analysis of the shape of a bar graph. 6b-6d, together with FIGS. 6b-6d, illustrate interactive imaging system diagnostics that derive qualitative system information according to the principles of the present invention. 6a, 6c, and 6d together with interactive imaging system diagnostics that derive qualitative system information in accordance with the principles of the present invention. 6a, 6b, and 6d together with interactive imaging system diagnostics that derive qualitative system information in accordance with the principles of the present invention. 6a-6c, together with FIGS. 6a-6c, illustrate interactive imaging system diagnostics that derive qualitative system information in accordance with the principles of the present invention. The figure which shows the example of a display of the result of an interactive imaging system diagnosis. 8b and 8c together with FIGS. 8b and 8c are logical flow diagrams illustrating the analysis of system diagnostic information obtained interactively by artificial intelligence processing. 8a and 8c together with FIGS. 8a and 8c are logical flow diagrams illustrating the analysis of system diagnostic information obtained interactively by artificial intelligence processing. FIG. 9B is a logical flow diagram showing analysis of system diagnosis information obtained interactively by the artificial intelligence process together with FIGS. 8A and 8B. FIG. 4 shows a display screen used for entering a diagnostic query for an interactive diagnostic system. FIG. 5 shows a display screen used to enter logic rules for an imaging system diagnostic processor using artificial intelligence. FIG. 4 illustrates another embodiment of the interactive imaging system diagnostic package of the present invention.

Claims (18)

Hardware components operated by software to perform diagnostic imaging procedures;
An imaging system maintenance system;
And the imaging system maintenance system comprises:
A maintenance program coupled to the hardware component of the medical diagnostic imaging system in response to initiation by an operator and receiving input from a component that interacts with the software for detection of software aging situations;
A display responsive to the maintenance program and indicating a result obtained by the maintenance program;
A medical diagnostic imaging system.   The software aging situation includes the number of temporary files, the number of backup files, the number of lost files saved, the number of browser history files, the amount of free hard disk space, the hard disk fragmentation, the number of committed bytes The medical diagnostic imaging system of claim 1, comprising one or more of a number, a number of pages read per second, a total number of bytes received per second, or a disk access time.   The medical diagnostic imaging system of claim 1, wherein the display is responsive to the maintenance program to recommend a course of action to solve a software aging problem.   The medical diagnostic imaging system of claim 3, wherein the display is responsive to the maintenance program to recommend the addition of system resources.   The medical diagnostic imaging system of claim 3, wherein the display is responsive to the maintenance program to recommend restarting the system to address a software aging situation.   The medical diagnostic imaging system of claim 3, wherein realization of the recommended behavioral policy improves system response time.   The medical diagnostic imaging system of claim 3, wherein the display is further responsive to the maintenance program to indicate an operator selection that at least partially improves software aging conditions upon selection. Hardware components operated by software to perform diagnostic imaging procedures;
An imaging system maintenance or repair system;
The imaging system maintenance or repair system comprises:
A maintenance / repair program that is responsive to an operator's initiation and is coupled to a source of information about imaging system usage and that operates to analyze the use of a medical diagnostic imaging system over a period of time;
A display showing the results obtained by the maintenance program in a manner that facilitates identification of usage characteristics that may cause imaging system problems;
A medical diagnostic imaging system.   The medical diagnostic imaging system of claim 8, wherein the information source includes a system log.   The medical diagnostic imaging system of claim 9, wherein the system log includes an error log.   The medical diagnostic imaging system of claim 8, wherein the usage characteristics indicate inefficient operation of the medical diagnostic imaging system.   9. The medical diagnostic imaging system of claim 8, wherein the display shows results obtained by the maintenance program in the form of a scatter diagram.   9. The medical diagnostic imaging system of claim 8, wherein the display shows results obtained by the maintenance program in the form of a bar graph. A method for improving the use of a medical imaging system comprising:
An acquisition step of acquiring usage data of the first medical imaging system;
A comparison step of comparing the usage data with usage data of a second medical imaging system;
A recommended step for recommending a change in use of the first medical imaging system;
Including methods.   15. The method of claim 14, further comprising the step of transmitting the usage data of the first medical imaging system to a repository of imaging system usage data comprising the usage data of the second medical imaging system.   The transmitting step sends the usage data of the first medical imaging system to a central repository of imaging system usage data comprising the usage data of the second medical imaging system and usage data of a third medical imaging system. The comparison step further comprises comparing the usage data of the first medical imaging system with the usage data of the second and third medical imaging systems. The method described in 1. A method for improving the repair of a medical imaging system comprising:
A decision step for determining a strategy for solving a problem with the medical imaging system;
A first transmission step of sending the strategy to a repository of repair information;
A second transmission step of sending the strategy to at least one other medical imaging system;
Including methods.   The determining step further comprises determining a strategy for solving a problem with the medical imaging system by a logic analysis program that takes into account a strategy for solving the problem as defined previously, 18. The transmitting step further comprises sending the strategy to at least one other medical imaging system that solves the problem with a previously defined logic analysis program that considers the strategy for solving the problem. The method described in 1.

Images