Computer graphics processing and selective visual display system – Display driving control circuitry – Controlling the condition of display elements
Reexamination Certificate
1996-08-13
2004-03-16
Nguyen, Cao (Kevin) (Department: 2102)
Computer graphics processing and selective visual display system
Display driving control circuitry
Controlling the condition of display elements
C345S960000
Reexamination Certificate
active
06707469
ABSTRACT:
FIELD OF THE INVENTION
This invention relates generally to medical imaging and more particularly, to a programmable imaging system.
BACKGROUND OF THE INVENTION
Medical imaging systems generally are utilized for imaging parts of patient's bodies for physician review. Different imaging technologies, sometimes referred to in the art as modalities, may be used for imaging patient body parts. Examples of imaging modalities include computed tomography (CT), magnetic resonance (MR), ultrasound, positron emission tomography (PET), and nuclear imaging.
With respect to generating, processing, and displaying medical images, the development of medical imaging applications generally requires significant software development effort. The development is usually performed by highly skilled software practitioners since specialized software skills are needed to develop graphical user interface (GUI) based medical imaging applications. The software engineers, however, have limited domain knowledge. The clinicians who actually use the software applications typically lack the software engineering skills required for developing the applications. It would be desirable to provide an imaging system which is highly usable so that clinicians can develop imaging applications.
Known “programmable” systems enable clinicians to generate customized imaging applications. The most simple type of customization, for example, allows customization of display screens for a particular physician or other requirements. More complex customizations are required, for example, for research institutions.
The known programmable imaging systems, however, have a number of shortcomings. For example, one known programmable system does not provide the capability of creating/customizing new GUI elements. In addition, such system is not integrated into the base system, which results in visual, functional, and usability problems. Also, only an experienced programmer can add functionality to the system.
The following sets forth additional shortcomings in known programmable imaging systems. These shortcomings generally relate to script generation and execution, asynchronous execution, and review template editor functions.
1. Script Generation and Execution
Scripts typically are utilized for controlling the display and processing sequence of medical image so that a physician who reviews the image can view the image data in a desired format. For example, a particular physician may prefer a particular sequence of views be displayed when viewing a particular organ. A script can be generated to control the image display so that the desired sequence of views is generated and displayed.
Generating fully functional and usable scripts from graphical user interface (GUI) based software applications is difficult. Typically, scripts are generated by recording GUI events, such as button clicks, and replaying the events in the same application. In many situations, however, it is desirable to produce output scripts that can be used within the context of a different processing environment. In these situations, the semantics of the actions performed by the user must be captured rather than a mere sequence of GUI events.
There are many examples of applications that provide facilities for recording and playing back GUI events at various levels. One such known program records the mouse movements, button presses and keyboard clicks, and replays these events. Even small changes to the GUI, however, requires that the events be re-recorded to capture the changes.
Another known application records the GUI widget (buttons, sliders, etc.) that was activated (pressed) rather than simple mouse and keyboard actions. This program alleviates the problem with minor GUI changes, but still requires playback of the created script on the original application. That is, this program only enables recording an application and playing it back using the same application. The scripts produced are not designed for use outside of the instrumented application. Additionally, the syntax of the output scripts produced are completely predetermined and are not user configurable.
2. Asynchronous Execution
Known medical imaging systems have a client server architecture. A major advantage of this architecture is that the application process can remain attentive to the user because the application does very little processing. Most processing is handled by servers. The servers, in turn, are “specialists” at providing a particular service and may in fact be running on specialized hardware, optimized for particular tasks. A good example of this specialization is a processing server having hardware acceleration of common image processing operations. The ability to access network distributed resources is a major advantage of the client-server architecture.
With respect to task execution in a client-server architecture, the application makes a request for some service. Because the servers(s) which process the requests can reside anywhere on the local area network, the application must wait for the operation to complete before reporting the results back to the user. The amount of time the application must wait depends on many factors, including the speed of the server. To remain interactive, the application must yield, which typically is performed by returning the execution thread to the idle state so that the application can respond to other user requests. This yielding function is fundamental to a highly interactive application. When the reply from the previously queued request arrives, the application must then restore the processing context of the application to its prerequest state and present the results of the operation. This process is commonly referred to as asynchronous behavior.
Experience has shown that implementation of the request-yield-reply paradigm introduces significant programming obfuscation because single operations must be broken up into multiple execution threads, state or context information must be managed to bind the request side to the reply side, and subtle, difficult to diagnose timing related errors can creep into the code due to multiple interactive asynchronous execution threads. The resulting code also is difficult to maintain. These factors have significantly reduced the productivity of programmers in this environment.
Moreover, the asynchronous execution application code is complex and advanced computer programming skills are required to develop code in this environment. For example, a six to eight week training period is typical for an experienced software engineer in the request-yield-reply development paradigm described above. Much of this training period is spent appreciating the finer points of asynchronous software programming. Further, the complexity of asynchronous programming makes it an unsuitable approach for most end users who are not usually software engineers. For the most part, developers of client-server applications have accepted the development inefficiencies of the request-yield-reply program paradigm as a penalty for the additional flexibility and high interactivity of client-server applications.
In addition, and in an attempt to avoid some shortcomings of asynchronous operation, some approaches exist in which database functions behave synchronously. For example, in one known approach, a programmer detects abnormally long operations and takes corrective actions. The mechanism used to implement this behavior is a polling mechanism where the GUI is frozen during the wait phase, i.e., it does not implement a true yield. In medical imaging and real time control applications where response latency must be very low, this type of mechanism may not be acceptable since an operator may have to respond to an emergency situation during long transactions. A further disadvantage of this approach is that long operations cannot be cancelled during the wait period. It would be desirable to provide a system in which application interactivity is preserved even during long transactions while eliminating the chores of coding in a request-yield-reply paradig
Armstrong Teasdale LLP
Horton Esq. Carl B.
Nguyen Cao (Kevin)
LandOfFree
Synchronous execution in a medical imaging system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Synchronous execution in a medical imaging system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Synchronous execution in a medical imaging system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3208043