Displaying radiological images

[0001] This document relates to displaying radiological images.

[0002] Medical images, such as X-rays, CAT (computerized axial tomography) scans, and MRIs (Magnetic Resonance Imaging), may be digitized to facilitate remote reading by radiologists. A hospital or other medical facility may use machines that capture and digitize the images and transmit them to a remote image server, such as a Picture Archiving and Communications System (PACS). The transmission may occur over a network, such as an intranet or the Internet.

[0003] Additionally, the hospital may also transmit orders corresponding to the images to an order server, such as a Radiologist Information System (RIS). The orders may be requests for a radiologist to interpret, or read, the images and return a diagnostic report. Orders may also contain information, such as a patient identifier, the procedure type associated with the image, patient demographic information, and a hospital identifier.

[0004] Radiologists can interpret medical images at a radiologist workstation. An image viewer application at the workstation receives the medical images and presents the medical images to the radiologist. The radiologist reviews the medical images and provides a report based on an analysis of the medical images. For example, the radiologist may provide a diagnosis of a particular medical condition, such as a tumor, based on the medical images.

[0005] A system for generating a normalized hanging protocol using files, metadata, and medical images generated by multiple sources may include a normalization module that analyzes and normalizes the medical images. The files and metadata may be used to realize a normalized hanging protocol for displaying medical images generated by the multiple sources.

[0006] In an illustrative implementation, multiple medical facilities may generate sequences of medical images that have embedded metadata which specifies the modality that generated the images, a default grouping of the images, and a default ordering of the images within the groups, wherein the default ordering and grouping may be specific to particular types of modalities or facilities. In some embodiments, the various medical images and metadata may be received at an image order management system that parses the metadata and assembles the metadata into manifest files that may be transmitted independently to remote viewing sites, which in turn may be equipped with image viewer applications that analyze the manifest files and determine a normalized hanging protocol of the medical images. The normalized hanging protocol can represent a normalized order or layout of a series of arranged images for optimal electronic viewing. The normalization can be executed as a function of similar image characteristics shared between the multiple sequences of medical images.

[0007] In such implementations, the remote viewing site's image viewer application may call for the transmittal or caching of images for display in a status bar interface where the remote user can interact with the images displayed in a normalized hanging protocol.

[0008] The systems and techniques described here may provide one or more of the following advantages. First, providing normalized hanging protocols can allow radiologists to work in a unified environment that presents data from different facilities in a uniform way, regardless of the organization of the metadata in a corresponding manifest file. Second, providing normalized hanging protocols may enhance radiologist productivity since the radiologist can view all images in a standardized layout or fashion. Third, providing a status bar having a single click control can provide the advantage of quick retrieval of metrics during a dictation phase of a typical image study analysis. Fourth, providing an automatic scrolling mechanism may improve radiologist efficiency and reduce computer-related repetitive injuries.

[0009] The details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.

[0016] Illustrative implementations of computer-based systems, methods, and interfaces for generating, displaying, and adjusting radiological images are described. The described systems, methods, and interfaces can enable a radiologist in a teleradiology environment to view, interact with, and analyze images, and to provide diagnostic findings to a medical facility.

[0017] Referring to FIG. 1A, an example teleradiology system 100 is shown. The system 100 can be used for capturing medical image data in one location and for reviewing medical images associated with the data in another location. The system 100 can include many geographically separated imaging devices and many image review terminals. For purposes of illustration, the teleradiology system 100 shown in FIG. 1 includes an imaging system 102, an image order (IO) management system 104, and an image review system 106. The imaging system 102, for example, may include an imaging device 110, such as a CT (computer tomography) scanner or an MRI (magnetic resonance imaging) scanner. Using an energy source such as X-rays or magnetic fields, for example, the imaging device 110 may capture image data associated with a subject 112 (e.g., a patient). In some implementations, the image data may include a series of two-dimensional images. In some implementations, the image data may be used to produce a three-dimensional model that can be further manipulated and reformatted for generating two-dimensional (or three-dimensional) images. Image data captured by the imaging device 110 can be stored and processed by an imaging device server 114 (e.g., one or more computers with a processor and a memory) and can be provided to other systems and computers in the system 100 through a network 120 (e.g. an intranet or the Internet).

[0018] In some implementations, image data may be provided to the IO management system 104, where the data may be stored and processed by one or more computers. For example, the IO management system 104 may determine that the image data is to be provided to a system user 132 (e.g., a radiologist) at the image review system 106. As shown, image data can be provided by the IO management system 104 to the image review system 106 through the network 120.

[0019] The image review system 106 may include an image display server 134 (e.g., one or more computers with a processor and a memory), a display device 136 (e.g., a monitor), and input devices 138A-B (e.g., keyboards, computer mice, joysticks, touch interfaces, voice interfaces, and the like). In some implementations, image data may be processed by the image display server 134 and visually presented to the user 132 as one or more images at the display device 136. Using the input devices 138A-B, the user 132 may interact with the presented images, for example, by manipulating one or more user controls included in a graphical user interface presented at the display device 136 in association with the images. For example, the user 132 may view an image (or a series of related images), and may specify one or more image adjustments, such as zooming, panning, rotating, changing contrast, changing color, changing view angle, changing view depth, changing rendering or reconstruction technique, and the like. By viewing and interacting with presented image data and with the user interface, for example, the user 132 may produce and indicate a diagnostic finding related to the subject 112.

[0020] In some implementations, the IO management system 104 generates one or more manifest files 140 that include a combination of medical images 144 and metadata 142 describing the medical images 144. The IO management system 104 may extract the metadata 142 from the medical images 144 and use the metadata 142 as a basis for modifying, reorganizing, or displaying information about the medical images 144. The IO management system 104 may generate one or more manifest files 140 that include the metadata 142 or additional metadata (not shown). The metadata 142 can be extracted from the medical images and compiled into the manifest file 140 that, for example, serves as a catalog, or manifest, of the medical images 144. The IO management system 104 can send the medical images 144 to a client device (e.g., image review system 106) independently of sending the manifest file 140 to the image review system 106. Similarly, the IO management system 104 can independently send the medical images 144 and the manifest file 140 to another client device (not shown). The image review system 106 (or another client device) may use the manifest file 140 to display, reorganize, analyze, or otherwise operate on medical images 144.

[0021] Each manifest file may include information about medical images arranged in a particular format. In an illustrative example, the manifest file may be generated using a Digital Imaging and Communications in Medicine (DICOM) format standard. The DICOM format includes metadata that describes the medical images. The manifest file 140 can, for example, describe an ordering and/or grouping in which to present the medical images 144. An image viewer application can receive the medical images 144 and present the medical images 144 in the ordering and/or grouping described in the manifest file 140.

[0022] In some implementations, the metadata 142 is embedded in a file that includes the medical images 144. For example, the metadata 142 may be included in header fields that accompany the medical image 144, where the header fields and the medical image 144 are transmitted together. In another example, an external requirement or regulation that applies to the medical image 144 may restrict separation of the metadata 142 from the medical image 144 (e.g., for compliance with the DICOM format standard).

[0023] FIG. 1B is a block diagram showing an example of additional components in the IO management system 104. The IO management system 104 includes an interface 150, a metadata extractor 152, and a manifest generator 154.

[0024] The IO management system 104 uses the interface 150 to send and receive files or other data. For example, the IO management system 104 can receive the medical images 144 from a medical facility through the interface 150. In some implementations, the IO management system 104 can send the medical images 144 and corresponding manifest files 140 to an image server 156 through the interface 150. The image server can perform further processing on the medical images 144 and/or manifest files 140.

[0025] The image server 156 analyzes medical images including metadata associated with medical images. For example, the image server 156 can analyze metadata 142 stored in medical images 144. The metadata may be public metadata or private metadata. Public metadata may include information about the image data, such as the size, dimensions, bit depth, modality used to create the data, and equipment settings used to capture the image, among other information. Private metadata may include user-defined or vendor-defined metadata fields which provide additional information about the data or images. Both public and private metadata can be included in the DICOM file format and provided to the IO management system 104 in a manifest file 140, for example.

[0026] The metadata extractor 152 extracts metadata from medical images. For example, the metadata extractor 152 can receive the medical images 144 from the interface 150 and extract the metadata 142. The metadata extractor 152 provides extracted metadata to the manifest generator 154. In some implementations, the metadata extractor 152 stores the extracted metadata, for example, in image storage 158.

[0027] The manifest generator 154 uses extracted metadata to generate manifest files. For example, the manifest generator 154 can receive the metadata 142 from the metadata extractor 152 and generate the manifest files 140. The manifest generator 154 can use metadata or user-entered information to generate manifest files which specify instructions for presenting images in a specific manner. For example, the manifest generator 154 can generate a manifest file 140 which specifies using specific metadata (e.g., sub-specialty of a medical professional, user-specified data, or specific image capture device) for displaying an image sequence in a particular layout or order. In some implementations, the manifest generator 154 stores the generated manifest files, for example, in the image storage 158. The IO management system 104 provides one or more manifest files 140 to the image review system 106 through the interface 150.

[0028] While the example shown in FIGS. 1A-1B include a few medical images, the IO management system 104 can receive a number of medical images associated with a particular order that is significantly larger than a few images, such as hundreds or thousands of images. In addition, a medically relevant sequence of images can include any of the medical images received from a medical facility as determined by processing of the associated manifest file. Additionally, the medically relevant sequence may only include a portion of the medical images generated by a modality at a medical facility.

[0029] FIG. 2 is a block diagram of an example system for generating a normalized hanging protocol. A hanging protocol typically represents an order or layout of a series of arranged images for optimal electronic viewing. A normalized hanging protocol represents a hanging protocol capable of presenting specific types of images received from multiple different facilities in a consistent manner. The normalized hanging protocol may be normalized to similar image characteristic data included in metadata in one or more manifest files 202 received from a number of facilities, for example. Similar image characteristic data may include public or private metadata information or user-specified data included in manifest files received from multiple facilities.

[0030] Normalized hanging protocols can allow radiologists to work in a unified environment that presents data from different facilities in a uniform way, regardless of the organization of the metadata in a corresponding manifest file (e.g., DICOM format file). The normalization can ensure that radiologists can work with derived sequences of images that are organized according to image and study semantics rather than the vagaries of one or more sending devices or medical facility. Normalized hanging protocols may provide the advantage of enhancing radiologist productivity, for example because the radiologist can view all images in a standardized layout or fashion.

[0031] Referring to FIG. 2, the IO management system 104 (FIGS. 1A and 1B) may also include a manifest file processing interface 202. The manifest file processing interface 202 can receive transmissions from multiple medical facilities. The transmissions can include one or more manifest files which associate medical images and metadata describing characteristics of the medical images. The manifest file processing interface 202 can receive one or more manifest files 204 from the interface 150, for example.

[0032] The manifest file processing interface 202 can generate a normalized hanging protocol 206 by performing multiple processes on received manifest files 204. The processes can, for example, be performed by a metadata interpretation module 208, a normalization module 210, and a rendering module 212. Each module 208-210 can perform a number of processes simultaneously or concurrently with other processing tasks.

[0033] The normalization process performed in the manifest file processing interface 202 can include extracting and interpreting metadata from one or more manifest files 204. For example, the metadata interpretation module 208 extracts and interprets image characteristic data stored in the metadata of the manifest files 204. The interpretation may include generating a set of display rules for displaying the medical images received from each manifest file 204 according to a default hanging protocol. The default hanging protocol represents a set of standardized display rules received in metadata and employed by the IO management system 104. The display rules can include, for example, guidelines detailing the number of viewing panes in a GUI, an arrangement of viewing panes, and the content of the viewing panes as provided by each individual medical facility. In some implementations, the normalization process can include comparing image characteristics in two or more manifest files received from multiple facilities to create a normalized hanging protocol template for use in displaying images in several facilities.

[0034] The normalization module 210 can receive, from the metadata interpretation module 208, a default hanging protocol (e.g., display rules). The normalization module 210 modifies the default hanging protocol to display the medical images stored in each manifest file in a normalized fashion. The normalization may include normalizing the default hanging protocol to similar image characteristic data included in the metadata in one or more manifest files. In some implementations, a similarity standard or convention in the medical field, or particularly in the field of radiology, can be used as a similarity criterion. Solely as illustration herein, the image characteristic data may include: a modality that generated the images, a default grouping of the images, a default ordering of the images within the groups, a patient name, a patient identifier, a patient birth date, medical technician comments, a sub-specialty of a medical professional, user-entered preferences, a time the particular image was taken, a position of the image relative to the patient, a DICOM series number (“series #”) that the image was originally included in, and the order of the image (“index”) in the DICOM series, to name a few examples. Other image characteristic data is possible.

[0035] In some implementations, specific metadata in the default hanging protocol is omitted as part of the normalization process, which can provide a least common denominator representation of image characteristic data across multiple manifest files 204. This normalization reduces the amount of metadata required to provide a particular hanging protocol to a radiologist. In some implementations, the normalized hanging protocol can provide radiologists with hanging protocols corresponding to a sub-specialty of a medical professional, based on user-specified data, or corresponding to a specific image capture device, just to name a few examples. The normalization module 210 can use the normalized hanging protocol to create a standardized document manifest to determine which hanging protocol to employ.

[0036] The manifest file processing interface 202 can employ the rendering module 212 to prepare and display medical images from each manifest file 204. The rendering module 212 can display particular medical images in a status bar interface at a client device according to the normalized hanging protocol. The status bar interface can be used to display thumbnail images that can be selected by a radiologist for review in a larger display. The status bar can include images as well as controls for manipulating images in the larger display.

[0037] FIG. 3 is an illustration of an example status bar interface 300. The status bar interface 300 provides thumbnail images and user controls, and indicates a status of which images have been previously reviewed, modified, added, or deleted. In some implementations, the interface 300 may be displayed at the image display device 136 by the image review system 106 (as shown in FIG. 1). For example, the user 132 may use any of the input devices 138A-B to interact with one or more user controls included in the interface 300 to specify image adjustments (e.g., zooming, panning, rotating, contrast, color, view angle, view depth, rendering or reconstruction techniques). Based on the specified adjustments, for example, the teleradiology system 100 may generate one or more adjusted radiological images based on information received from the controls, and may present the adjusted image(s) at the image display device 136.

[0038] The status bar interface 300 depicts an interactive graphical user interface (GUI) for presenting, reviewing, and manipulating medical images organized according to a particular hanging protocol. The status bar interface 300 provides a number of image sequences here represented by respective thumbnails 302a-f. The thumbnail 302a represents an “all” sequence with a count of 321 images in the sequence. The thumbnails 302b-f represent “series #1” through “series #5,” respectively. In some implementations, a sequence can be displayed according to a default hanging protocol. The default hanging protocol may display images in multiple panes according to each manifest file accompanying each image series. In some implementations, a sequence can be displayed according to a normalized hanging protocol. Each received image series can be analyzed by the IO management system 104 to determine similar image characteristics between the series. A similar image characteristic may involve image characteristics that are common to two distinct images. The commonality may be found in image metadata, image attributes, or other associated image data stored with each image file. The similar image characteristic can be deduced by comparing image data found in a manifest file associated with each image or image sequence, for example. The similar image characteristics can be used to organize and present images according to the normalized hanging protocol in a corresponding GUI (not shown).

[0039] The status bar interface 300 includes a status indicator 304 that indicates a review status for previously viewed images and a cache status of medical images in a study. For example, the status indicator 304 illustrates a placeholder in a sequence of images where a radiologist can continue reviewing images which have yet to be reviewed. A radiologist can use the status bar interface 300 for quickly ascertaining whether specific images or series of images have been reviewed. If the radiologist determines that one or more images or series have not been reviewed, the radiologist can jump to the unviewed images with a single-click control located on the status bar interface 300. For example, while a radiologist is viewing an image sequence, a single click in the sequence may cause the status bar interface 300 to jump to the next unviewed image within the current image sequence and display the next unviewed image in a larger display screen. If the radiologist decides to close out a study, the status bar interface 300 may generate a warning message that warns the radiologist of unviewed images and/or unviewed image series.

[0040] In some implementations, the status bar interface 300 can be used to review measurements, annotations, and/or key images that a radiologist has marked during the course of a read via a single click or selection of a button. Each reviewable metric can be displayed in a tiled mode on each available screen with the same imaging settings that were in effect when the metric was created or edited. Providing a single click control on the status bar interface 300 can allow quick retrieval of metrics during a dictation phase of a typical study read.

[0041] In some implementations, the status bar interface 300 may support an automatic scrolling mechanism. The scrolling mechanism can be triggered using an integrated ergonomic device, such as VRGrip, a standard mouse, joystick, or other scrolling capable hardware. The scrolling mechanism can facilitate image review by successively flipping through a series of images thus creating a motion picture, or automatic cine, of a particular patient's image series. The scrolling mechanism can be triggered with a single movement forward (using scrolling hardware) that sets an acceleration speed and immediately begins scrolling forward through an image sequence at the set acceleration speed. Similarly, the scrolling mechanism can be triggered by a single mouse movement sideways or backward to begin scrolling sideways or backward, respectively. If the scrolling is moving in a forward direction, the user can slow the scrolling speed by moving the scrolling hardware in a backward direction.

[0042] In general, scrolling speed can be increased and decreased depending on the amount of cursor movement, relative to the cursor's position at the time a cine is invoked by a user. For example, the user can use an input device, such as a mouse, in the same manner one would use a throttle mechanism. That is, the farther the user moves a mouse, the faster the cine scrolls. Similarly, the less the user moves the mouse, the slower the cine scrolls. The automatic scrolling mechanism may provide the advantages of optimizing radiologist efficiency and minimizing computer-related repetitive injuries since a constant scroll movement by the user is no longer required when employing the automatic scrolling mechanism.

[0043] FIG. 4 is a flow chart showing an example process 400 for normalizing a display protocol in a Picture Archiving and Communications System (PACS). In some implementations, the process 400 may be performed by the system 200 (as shown in FIG. 2). In some implementations, the process 400 may be performed by the system 100 (as shown in FIG. 1). A particular order and number of steps are described for the process 400. However, it will be appreciated that the number, order, and type of steps required for the process 400 may be different in other examples.

[0044] In step 402, an image order management system (e.g., image order management system 104) receives one or more manifest files from medical facilities. The manifest files may include medical images and associated metadata describing characteristics of the medical images.

[0045] In step 404, a metadata interpretation module may extract the image characteristic data stored in the metadata of the manifest files and interpret the metadata. The metadata interpretation module can use interpreted metadata to generate display rules for displaying the medical images in each manifest file according to a first default hanging protocol.

[0046] In step 406, the metadata interpretation module may determine similar image characteristics included in the metadata in one or more manifest files. The similar image characteristics may in some implementations include user preferences, medical specialty, image semantics, and/or study semantics. For example, similar image characteristics of user preferences can include physician image layout preferences, radiologist image layout preferences, facility image layout preferences, and/or preferred header information. For example, similar image characteristics of medical specialties can include specialties such as oncology or neurology or a sub-specialty such as radiation oncology or neuroradiology. For example, similar image characteristics of image semantics can include definitions or specific details about an image, including, but not limited to, physicians notes, patient requests, etc. For example, similar image characteristics of study semantics can include definitions or specific details regarding each image in an image study, including, but not limited to, file names, series name, patient history.

[0047] In step 408, a normalization module (e.g., normalization module 210) may modify the display rules to normalize the default hanging protocol into a normalized hanging protocol according to the determined similar image characteristics.

[0048] In step 410, a rendering module (e.g., rendering module 212) may render the medical images in at least the normalized hanging protocol. In step 412, the rendering module 212 may present the medical images in the normalized hanging protocol in a status bar display on a client device.

[0049] FIG. 5 shows an example block diagram of a teleradiology system 500 including an image order management system 502, medical facilities 504, and client devices 506 connected by a network 508, such as the Internet. The medical facilities 504 may send images and orders for studying the images to the IO management system 502, as represented by arrows 510 and 512. The images may include representations of body parts such as X-rays, CAT scans, and MRIs. The images may also contain information, such as which medical facility sent the image, the number of images in the transmission, the patient name, and other patient demographic information. The orders may contain information about a patient, such as name, medical history, and the reason the image was taken. The order may also include a description of an associated image, such as a pelvic abdominal scan, a number of images associated with the order, and an order type, such as preliminary or final read. The presence of the patient name and other patient information may enable a particular image to be linked with a particular order. The IO management system 502 may store the images and orders and assign the orders to appropriate users at the client devices 506. For example, the IO management system 502 may assign an order from a medical facility 504A to a radiologist at a client device 506A. If the radiologist accepts the order, the IO management system 502 may make the images associated with the order available to the radiologist for viewing, as indicated by arrows 514 and 516. The radiologist can interpret the images and send a report back to the IO management system 502, as represented by arrows 518 and 512. The IO management system 502 may then forward the report to the originating medical facility, as indicated by arrows 514 and 520, where the report may be used in a diagnosis for the patient.

[0050] The IO management system 502 may be implemented on a single computing device or on multiple computing devices, such as a server farm. In some implementations, the IO management system 502 may be disbursed over several servers that are connected through a network. This configuration may enable expansion of the system and flexibility in managing the flow of received and output images and orders.

[0051] Medical facilities may send images and orders at the same time as one another or at different times. Images, orders, and reports may be sent over the same network or different networks. For example, the IO management system 502 may receive images and orders through a single T1 connection to the Internet, or the images may be received from the Internet through a T1 connection and the orders may be received through a modem connection. As another example, the IO management system 502 may receive an image and an order from a medical facility over the Internet and return a corresponding report to the medical facility over a fax connection.

[0052] The images and orders may be sent separately or combined in one transmission. For instance, a computing device at a medical facility may use software that sends the orders and the images with a single application and single set of actions, or the medical facility may send the images using one application that sends one transmission and send the orders using a different application that sends a separate transmission.

[0053] In some implementations, the network 508 may be a secure network, such as a virtual private network (VPN). The VPN may include a secure computing device or terminal at the medical facility 504, at the IO management system 502, and at the client device 506. Encrypted transmissions (e.g., of image and order data) sent through the network 508 between the medical facility 504, the IO management system 502, and the client device 506 may also include the use of other forms of secure communications, such as the Secure Socket Layer (SSL), Terminal Services, and Citrix systems.

[0054] The IO management system 502 can include an access control module 522 that controls user access to the IO management system 502. Users may include staff at a hospital, imaging center, medical research facility or other medical facility and radiologists at the client devices 506, to name a few examples. For example, the access module 522 may include a remote desktop application, such as Terminal Services, that allows users to login to the IO management system 502. As another example, the access control module 522 may include an application portal accessible from the remote desktop or from the Internet with individual logins and passwords for each user. If the access control module 522 grants access to a user at the medical facility 504A, the user may be able to send images and orders or receive reports, as indicated by arrows 524 and 526, respectively. If an order is assigned to and accepted by a radiologist at the client device 506A, the radiologist may be able to retrieve the order and its images or send a report. The access control module 522 may also monitor the connectivity status of the medical facilities 504 or the client devices 506. For example, control module 522 may monitor whether a secure network connection between the medical facilities 504 or the client devices 506 and the I/O management system 502 is operational.

[0055] When image data is received by the IO management system 502 and accepted by the access control module 522 it may be sent to a production module 530. The production module 530 may handle real-time processing in the IO management system 502, such as managing the workflow of orders and images. The production module 530 may forward the image data to an image server 532, as indicated by arrows 534 and 536, for processing and storage. For example, the image server 532 may be part of a Picture Archive Communication System (PACS), which may digitally store, process, transmit, and facilitate the display of radiology images.

[0056] In some implementations, the production module 530 and the image server 532 may not communicate in the same format, so a messaging module 548 may handle communications between the two. For example, if the production module 530 is able to read text files as input, the messaging module 548 may take output from another source, such as the image server 532, and convert it into a text file format that the production module 530 can interpret.

[0057] When an order is received by the IO management system 502 and accepted by the access control module 522 it may be sent to the production module 530. The production module 530 may forward the order to an order module 550, such as a Radiology Information System (RIS), as represented by arrows 534 and 552, for processing. The messaging module 548 may process communication between the production module 530 and the order module 550.

[0058] Once the IO management system 502 receives an order, the production module 530 may assign the order to a user of a client device 506. The production module 530 may also assign the order to several users at several client devices 506. If the access control module 522 grants a user of a client device access, the user may retrieve orders from the order module 550 and image data from the image server 532, as indicated by arrows 554, 556, and 558.

[0059] The IO management system 502 may include a data module 560 that stores data associated with the system 502. For example, order data used by the order module 550 and image data used by the image server 532 may be stored by the data module 560. In some implementations, image data may be stored by the image server 532.

[0060] FIG. 6 is a schematic diagram of a generic computer system 600. The system 600 can be used for the operations described in association with any of the computer-implement methods described previously, according to some implementations. The system 600 includes a processor 610, a memory 620, a storage device 630, and an input/output device 640. Each of the components 610, 620, 630, and 640 are interconnected using a system bus 650. The processor 610 is capable of processing instructions for execution within the system 600. In some implementations, the processor 610 is a single-threaded processor. In some implementations, the processor 610 is a multi-threaded processor. The processor 610 is capable of processing instructions stored in the memory 620 or on the storage device 630 to display graphical information for a user interface on the input/output device 640.

[0061] The memory 620 stores information within the system 600. In some implementations, the memory 620 is a computer-readable medium. The memory 620 is a volatile memory unit in some implementations and is a non-volatile memory unit in other implementations.

[0062] The storage device 630 is capable of providing mass storage for the system 600. In some implementations, the storage device 630 is a computer-readable medium. In some implementations, the storage device 630 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device.

[0063] The input/output device 640 provides input/output operations for the system 600. In some implementations, the input/output device 640 includes a keyboard and/or pointing device. In some implementations, the input/output device 640 includes a display unit for displaying graphical user interfaces.

[0064] The features described can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The apparatus can be implemented in a computer program product tangibly embodied in an information carrier, e.g., in a machine-readable storage device, for execution by a programmable processor; and method steps can be performed by a programmable processor executing a program of instructions to perform functions of the described implementations by operating on input data and generating output. The described features can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. A computer program is a set of instructions that can be used, directly or indirectly, in a computer to perform a certain activity or bring about a certain result. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0065] Suitable processors for the execution of a program of instructions include, by way of example, both general and special purpose microprocessors, and the sole processor or one of multiple processors of any kind of computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memories for storing instructions and data. Generally, a computer will also include, or be operatively coupled to communicate with, one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).

[0066] To provide for interaction with a user, the features can be implemented on a computer having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer.

[0067] The features can be implemented in a computer system that includes a back-end component, such as a data server, or that includes a middleware component, such as an application server or an Internet server, or that includes a front-end component, such as a client computer having a graphical user interface or an Internet browser, or any combination of them. The components of the system can be connected by any form or medium of digital data communication such as a communication network. Examples of communication networks include, e.g., a LAN, a WAN, and the computers and networks forming the Internet.

[0068] The computer system can include clients and servers. A client and server are generally remote from each other and typically interact through a network, such as the described one. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

[0069] A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of this disclosure. Accordingly, other implementations are within the scope of the following claims.