Picture archiving and communication system6574629Abstract A picture archiving and communication system ("PACS") includes plural core components arranged in a cluster. These core components include an archive station which includes long-term storage for storing image data, and a reviewing station which includes a display for displaying images based on received image data. Also included is a network gateway which interfaces to a non-core component so as to receive image data therefrom, and which routes the image data to at least one of the archive station and the reviewing station based on a set of rules in the network gateway. Finally, a database server manages access to the image data, and stores information relating to the image data. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
TABLE 1
PACS Core Components
Core Component Role in PACS
Archive Station Provides long-term DICOM archive for
("AS") permanent storage and retrieval of studies, i.e.,
a digital file room. There are two types
of archive stations used in the invention:
a magneto optical disk ("MOD") - based
station, and a digital linear tape
("DLT") - based station.
Network Gateway Performs DICOM validation and print
("NWG") services, network compression, radiology
information system ("RIS") validation,
AGFA .RTM. PACS Interface Protocol
("APIP") translation, and workflow automation,
including routing, pre-fetching of prior
relevant patient images, and generation
of user-defined demographic overlays.
Database Server Manages and shares information related to
("OS") study attributes, system configuration,
user accounts, study mark-up, and annotation.
Review Station Comprises full-featured, multi-modality,
("RS") dual monitor diagnostic and clinical display
stations with access to the archive station
and an RIS report database.
FIG. 1 shows a typical PACS cluster in accordance with the present invention. Specifically, core PACS cluster 1 includes a database server 2, one or more archive stations 4, and one or more network gateways 6 located in a secure, air-conditioned computer room, with one or more reviewing stations 7 spread throughout the facility (e.g., the hospital) and connected to the remaining core components by a fast switched TCP/IP network 9. Each of these core components is loaded with appropriate PACS software modules to effect specific PACS functions. Because of the modular design of this software, it is possible to combine several PACS software modules in one workstation, and thereby provide a workstation that handles, e.g., both the archiving and network gateway functions. However, for the sake of clarity, the invention is described using a separate workstation for each function. As also shown, additional PACS components, called "extensions", may be interfaced to the core components to effect various functionalities, as described below in section 1.6. 1.1 Workstation Hardware FIG. 2 shows a general hardware configuration for each PACS core component and extension noted above. Of course, each of the core components and extensions includes specific software, and may include additional hardware, for performing its unique function. In addition, certain extensions, such as a printer, are clearly not defined by the hardware shown in FIG. 2. However, each PACS station that can be implemented by a workstation, or personal computer ("PC"), preferably has the following features shown in FIG. 2. Therefore, a general discussion of these features is provided here, followed below by detailed descriptions of additional hardware and software for each PACS component/extension. As shown in the figure, workstation 10 includes one or more network connections 11 for interfacing to a network, such as the PACS DICOM network and the Internet, and one or more fax/modem connections 12 for interfacing with other remote sources. Workstation 10 also includes one or more display screens 14 for displaying information to a user, keyboard 16 for inputting text and user commands, and mouse 17 for positioning a cursor on display screen 14 and for inputting user commands. Workstation 10 may also include disk drive 19 for reading from and writing to floppy disks installed therein, and CD-ROM drive 20 for accessing information stored on CD-ROM. FIG. 3 shows the internal architecture of workstation 10. As shown in FIG. 3, workstation 10 includes memory 21, which comprises a computer-readable medium such as one or more computer hard disks. A portion of memory 21 may comprise a cache 23 for the workstation. In addition, memory 21 stores data 22, applications 24, print driver 25, PACS software modules 26, and an operating system 27. The applications and operating system of each workstation varies for each PACS component, as described below. At least some of PACS software modules 26, however, are included on each PACS component in order to effect the storage, routing, retrieval, transmission, display, and printing of medical (or other) images described herein. Generally speaking, these PACS software modules comprise computer-executable code that defines process steps for effecting the various PACS functions of each component/extension. In this regard, it is noted that since each PACS component/extension does not need to perform all PACS functions, it is generally not necessary to load all of the PACS software modules onto each component/extension. Rather, only those modules needed to effect the specific functionality of that component/extension need be loaded. As noted above, however, modules for performing different PACS functions (e.g., archiving and network gateway functions) may be loaded into the same workstation, if desired. Also included in workstation 10 are display interface 29, keyboard interface 30, mouse interface 31, computer bus 32, RAM 34, processor 36, printer interface 37, and possibly disk drive interface 39 and CD-ROM drive interface 40. Processor 36 comprises a microprocessor (the type of which varies depending upon the station, as described below) for executing the applications and PACS software modules out of RAM 34. In this regard, RAM 34 can comprise several memory devices. The applications and PACS software are preferably stored in memory 21, as noted above. Alternatively, however, applications may be stored on a floppy disk in disk drive 19 or a CD-ROM in CD-ROM drive 20. In this case, processor 36 accesses these applications (or other data) stored on a floppy disk via disk drive interface 39 and accesses applications (or other data) stored on a CD-ROM via CD-ROM drive interface 40. Application execution and other tasks of workstation 10 may be initiated using keyboard 16 or mouse 17, commands from which are transmitted to processor 36 via keyboard interface 30 and mouse interface 31, respectively. Output results from applications running on workstation 10 may be processed by display interface 29 and then displayed to a user on display 14. To this end, display interface 29 preferably comprises a display processor for forming images based on data provided by processor 36 over computer bus 32, and for outputting those images to display 14. Rather than including a separate display processor, the functionality of display processor 36 may be implemented by processor 36. Output results from the PACS software modules, e.g., medical images, may also be output to network printers, such as those described below in section 1.6.7. To this end, processor 36 executes print driver 25 which performs appropriate formatting of the output results prior to their transmission. Local printers also may be attached to various stations, if desired, which can be accessed via printer interface 37. 1.2 Archive Station Archive station 4 comprises a workstation 40 having a memory device 41 connected thereto. This memory device comprises central and secure near and long-term DICOM storage for studies provided from imaging modalities. In this regard, a "study" comprises a series of images captured by an imaging modality. The invention described herein can be used to manage folders of studies, individual studies, series of images, or individual images. Accordingly, henceforth, these terms can be used interchangeably. Included on archive station 4 is software for controlling reading from, and writing to, memory device 41 in response to requests/instructions received from other core components, most notably reviewing stations 7, network gateway 6, and the extensions. The software also generates a graphical user interface ("GUI") (not shown), which provides the PACS administrator with the ability to manually control deleting, splitting and merging of studies, as well as querying, transmitting and retrieving studies. These operations are described in detail below. There are also configurable privilege level security controls on the GUI to prevent unauthorized persons from accessing archive configuration and management tools. In preferred embodiments of the invention, original image data is stored on the archive station, and that original image data does not change, meaning that retrieved and edited images are not stored back to the archive station. Instead, edited images and the like are stored to database files on the archive station. These database files are preferably stored in a hard disk or the like on workstation 40, and comprise a collection of all information relating to studies and parameters associated with setup of the PACS. An example of information stored in the database is demographic information associated with each patient and study. As noted in Table 1 above, the archive station may comprise either a magneto optical disk (or "MOD")--based archive station, or a digital linear tape (or "DLT")--based archive station. 1.2.1 MOD-Based Archive Station The MOD-based archive station includes a three-tiered storage system that uses hard disks (preferably 4 giga-bytes each) for on-line data storage (usually one week's worth of data), MODs (i.e., high-capacity, removable storage media having preferable either 2.3 or 4.6 giga-bytes of storage each) for intermediate-term data storage (usually one to two years), and DLT media for long-term backup storage. Additional RAID ("Redundant Array of Inexpensive Disks") may also be provided for expanded short term storage, depending upon the storage requirements of the facility and the number of studies handled thereby. The portion of short term storage, i.e., the RAID and other hard disks, which stores images comprises the MOD-based archive's cache. In a MOD-based archive station, the MODs themselves are housed in scalable optical disk jukeboxes. An optical disk jukebox is a mass storage device that reads data from, and writes data to, MODS (or, alternatively, to DLTs). Here, each optical disk jukebox preferably holds between 20 and 500 MODS, or up to 4 tera-bytes of memory total. Each MOD-based archive station drives one optical disk jukebox, and provides both manual and automatic control of data migration from short term storage to the MODs. With respect to manual control, the PACS administrator prepares and loads MODS into the jukebox, supports requests for off-line volumes, and periodically checks station queues using queue management and service tools provided on the archive's user interface. In preferred embodiments of the invention, the workstation also runs an "auto-pilot" routine which patrols the archive's cache and which automatically deletes studies once they have been archived on a MOD. This is done in order to prevent the cache from "overflowing". Certain studies may be protected from this auto-deletion by assigning them a "protected" status. This is described in detail below. 1.2.2 DLT-Based Archive Station In the MOD-based archive station described above, DLT is configured to backup the primary long-term storage in order to provide data redundancy. On the other hand, in the DLT-based archive station, the DLT is used for primary intermediate and long-term storage. In preferred embodiments, DLTs having a storage capacity of 35 giga-bytes each are used; although the invention can be used with DLTs having other storage capacities as well. The DLTs are stored in scaleable DLT jukeboxes, preferably capable of holding 30/100 588 DLTs, where one workstation drives one jukebox. In addition, MODs may also be provided for additional and/or backup intermediate and long-term storage. As above, RAID and hard disks are also provided for short-term storage of studies and for database storage. The DLT-based archive station provides both manual and automatic control of data migration from short term storage to DLT. These controls are substantially similar to those described above with respect to the MOD-based archive station and, therefore, are not repeated here for the sake of brevity. 1.3 Network Gateway Generally speaking, the network gateway is the "workflow manager" of the PACS, meaning that it receives images (as image data) from various non-core components including imaging modalities, confirms the validity of the received images, and routes them appropriately. To this end, the network gateway comprises a workstation that supports at least six, preferably more, simultaneous associations with DICOM-compliant imaging modalities. These modalities include, but are not limited to, X-ray, CT, MRI, NM and US modalities. Depending upon the number of imaging modalities, the PACS may use several network gateways in each cluster in order to provide load balancing and enhanced throughput. As shown in FIG. 1, network gateway 6 is in communication with reviewing stations 7 and imaging modalities 42 via the DICOM network, and is in communication with remote sources, such as the hospital's RIS 44 and various other PACS extensions. The network gateway thus receives studies from one or more imaging modalities and/or from the remote sources, and provides DICOM security and validation services therefor. To this end, the network gateway preferably includes optical character recognition ("OCR") and APIP translation capabilities to accommodate non-DICOM 3.0 imaging modalities. The network gateway also controls routing of these studies to selected PACS core components and extensions, and pre-fetching and routing of relevant prior studies between the archive and reviewing stations. Rules for routing and pre-fetching studies may be based on a number of factors, as described in more detail below in section 2. Among the other services provided by the network gateway is RIS validation. RIS validation ensures integrity of patient demographic information in the studies. To this end, the network gateway captures and stores studies in a private cache located, e.g., in a hard disk on the network gateway, so that key demographic information (e.g., patient identification, accession number, etc.) can be validated based on pre-stored information, as described in more detail below. The network gateway also provides DICOM print management services for the PACS cluster in which it resides. To this end, the network gateway includes routines which perform JPEG network compression and 12-to-8 bit simplification to accommodate DICOM printers, third party DICOM interfaces, and referring physician software, such as RP5. Workflow extensions resident on the network gateway also allow users to generate custom demographic overlays for images/studies. Finally, the network gateway also includes comprehensive queue management and service tools, as well as configurable privilege security controls to prevent unauthorized persons from accessing the gateway's configuration tools. 1.4 Database Server In preferred embodiments of the invention, database server 2 is an Oracle.RTM. V.7.3.X database server with RAID storage; however, it is important to note that the invention is not limited to use with this type of server. In general, the database server performs a variety of functions relating to retrieval and storage of studies located in the archive station(s). Among other things, the database server collects, organizes and manages patient and study demographic data that is contained in DICOM header files of each study. To this end, the database server stores all study attributes, including, but not limited to, image annotations and edits, window/level settings, measurements, and radiologist comments. The database server also stores all system configuration settings, including, but not limited to, user accounts, user profiles (i.e., a set of attributes associated with each login ID), preferred routings, demographic overlays, and DICOM network connectivity. The database server keeps track of where all studies "live" at the time, meaning the current location of a study in the PACS cluster. Thus, all query, transmit, retrieve, store and print actions initiated by a client, i.e., a PACS station, go through the database server (either directly or via the network gateway). As a result, database server 6 effectively manages access to images throughout the PACS. Comprehensive queue management and service tools are provided in the database server to effect these functions. Moreover, in preferred embodiments of the invention, advanced system monitoring tools are also included in the database server, which alert the PACS administrator that service or manual intervention is required. As a general rule, studies are not stored on the database server, unless the server also includes software modules to effect other core PACS functions. However, in most cases, the database server is a dedicated workstation with no archive or gateway functionality. Additional hardware, however, may be required to meet the facility's study volume, number of client stations, and required levels of performance and accessibility. 1.5 Reviewing Stations Reviewing stations 7 are workstations that may be used to retrieve and to view medical images handled by the PACS, as well as information relating thereto. The reviewing stations may be located remotely from the other PACS core components; that is, either remotely inside the same building/facility or remotely at a separate geographic location. In either case, a network (e.g., LAN, WAN, or the Internet) links the reviewing stations to the other PACS core components, in particular to network gateway 6. Each reviewing station preferably comprises a dual monitor, multi-modality, reading station with features provided by PACS software modules, including, but not limited to, window/level adjustment, image magnification, roam and zoom, and image annotation and measurement. The reviewing stations also perform automatic worklist generation and updates as relevant studies arrive. Regarding worklist generation, upon logging in to the PACS via a reviewing station, a user may enter a query asking the PACS to locate a study or group of studies based on input criteria, such as an accession number, which is a unique identifier for each study. Once these studies have been located, the PACS generates, and the reviewing station displays, a user interface called a main study window. This main study window is comprised of action buttons, system status indicators, and a main study list which includes studies that match the input criteria. The worklist comprises the study, or group of studies, that the user selects from the main study list. The reviewing stations provide users with the ability to view one or more such selected studies in a variety of different, selectable display formats, and then to print or transmit the studies using a displayed tool bar. With regard to viewing the studies, the reviewing stations may be modality-specific as is the case in FIG. 1. Therefore, they may have modality-specific viewing options, including, but not limited to, CT scout mode, MR cursor mode, image zoom, CINE loop, and image drag and drop features, all of which are described below. The viewing options also may include the ability to display multiple studies for the same patient on a single reviewing station. Flexible controls are generally provided for navigating through the larger studies. The invention also provides a way to customize the main study window and tool bar based on a user profile. Other options provided on the reviewing stations include the ability to access RIS reports and to create summary series folders for a patient, which summary series folders comprise selected patient images from one or more studies. In preferred embodiments of the invention, four different types of reviewing stations may be used in the PACS; although the invention is not limited to these four. Specifically, each PACS cluster may include only one, or more than one, type of these reviewing stations. Table 2 below lists features of these reviewing stations.
TABLE 2
PACS Reviewing Stations
Hardware
Designation Application Platform Monitors
RS5000 De-configured clinical Sun .RTM. Ultra 1, 1280 .times. 1024
review (plain film) 170 monochrome
RS3000 CT/MR/TO radiology Sun .RTM. Ultra 2, 1280 .times. 1024
primary reading 1200 Hi-bright
monochrome
RS3000 US/NM radiology Sun .RTM. Ultra 1, 1280 .times. 1024
Color primary reading 1200 Hi-res color
RS3000 CR/CT/TO radiology Sun .RTM. Ultra 2, 2048 .times. 2560
2K Portrait primary reading 1200 Hi-bright
monochrome
Each reviewing station may include a hard disk, RAID, or the like, which acts as its local cache. In reviewing stations of this type, prior to display, images are loaded into the cache, and then later retrieved at display time. Alternatively, the invention may operate with cache-less reviewing stations. In this case, images are routed to the reviewing stations when they are to be displayed, rather than being stored in the reviewing station's cache. In this regard, in the present invention, the images are generally routed from a cache in the archive station or the network gateway. Advantages of using cache-less reviewing stations include reduced network overhead and reduced memory capacity in, and thus reduced cost of, the reviewing stations. In other respects, cache-less reviewing stations behave similarly to their "cached" counterparts, except that they do not use a DICOM retrieve process, and the is PACS does not route or pre-fetch studies to a cache-less reviewing station. Routing and pre-fetching are described in detail below. 1.6 PACS Extensions As shown in FIG. 1, in addition to the core components described above, the PACS may include one or more extensions. These extensions provide added functionality to the system. For example, extensions exist which provide connectivity to a hospital's information system ("HIS") (i.e., the hospital's computer information system that integrates lab results, billing, and inventory) via the RIS. Extensions also exist which provide, among other things, low-cost referring physician display, DICOM printing, and translation services for non-DICOM 3.0 imaging modalities. In general, PACS extensions exist as stand-alone entities outside the cluster of core PACS components, and are not clients of database server 2. With one exception, namely the medical gateway described below, communication between the core components and the extensions preferably occurs through DICOM 3.0 "transmit/query/retrieve/store/print" protocols. 1.6.1 PACS Broker PACS broker 46, also referred to herein as the RIS gateway, provides an orderly, unified view of RIS 44 to the PACS core components, referring physician or clinical stations, a diagnostic center (e.g., the AGFA.RTM. Diagnostic Center, or "ADC"), and a transmitting station. Specifically, PACS broker 46 is a stand-alone platform that listens to the RIS and responds to query/retrieve statements from the PACS core components by accessing appropriate data from the RIS. To this end, PACS broker 46 is able to communicate in HL-7 ("Health Level 7") with the RIS, and to communicate in DICOM with network gateway 6. Thus, the PACS broker makes patient demographics, schedules, study parameters, and reports on the RIS available to the core PACS components. A PACS broker, or its equivalent, is therefore generally used if image/study routing is to be performed by the network gateway based on referring physician or patient location. Moreover, the PAC broker can be programmed to update patient information in the core components periodically, thereby ensuring that the PACS has the latest patient information available. In preferred embodiments of the invention, the PACS broker comprises a workstation which includes a color monitor and which runs Windows.RTM. NT. The workstation also preferably includes a disk drive which is at least 9 giga-bytes in size, for storing RIS reports, among other things. The PACS broker is interposed between the RIS and the network gateway, as shown in FIG. 1, and, in preferred embodiments of the invention, is connected to each via a TCP/IP network connection or the like. Of course, the invention is not limited to using this hardware to implement the PACS broker; any suitable computing equipment will do. 1.6.2 Web Server As noted above, one of the advantages of the present invention is the ability to access images/studies from remote locations, such as over the Internet. To this end, the present invention provides Web server 47 for making information on the Internet available to the PACS, and vice versa. Of course, standard security protocols are provided in Web server 47 to prevent unauthorized persons from gaining access to information stored on the PACS. In preferred embodiments of the invention, Web server 47 is a 100% JAVA server that provides a "no plug-in" solution for client viewing. In these embodiments, Web server 47 uses Sun.RTM. Ultra 2200 as its hardware platform, and supports 200 or more clients. Using this hardware platform, up to 50 clients may access the server concurrently. These clients may be any PC or Sun.RTM. workstation running a Hot JAVA browser or Netscape.RTM. Communicator. Web server 47 can be configured as a client of database server 2 (i.e., as a core component) or as a stand-alone system (i.e., as an extension). In either case, in response to a request from the PACS or the Internet, Web server 47 retrieves studies (or other information) from either the PACS or from the Internet in accordance with the request. The Web server then places those studies (or other information) into its cache, which is preferably scaleable to meet the storage needs of the system. Web server 47 may then provide either full-size images of those studies or thumbnail sketches thereof to the requester. Storing the images on the Web server in FlashPix.RTM. format (developed by the Digital Imaging Group) is one way for the Web server to provide ready access to either thumbnail or full-size images. In the case of data going out to the Internet, Web server 47 performs progressive wavelet compression on the data before it is transmitted. In a case that the Web server receives compressed data from the Internet, it performs progressive wavelet decompression prior to transmission to the PACS. The invention, of course, can support compression and decompression methods in addition to these. Using compressed data enables the Web server to support almost any type of network connection to the PACS core components including, but not limited to, LAN, WAN, POTS, ISDN, etc. Moreover, it speeds up data transmission time. 1.6.3 Referring Physician Station Referring physician stations are loaded with RP5, and generally comprise single monitor workstations designed for referring physicians home/office use (as opposed to primary viewing). In this regard, RP5 software comprises PC-based DICOM "query/retrieve/display/report/print" software that can be loaded onto any suitably equipped workstation. Version 1.X of RP5 is a 16-bit application which runs on a variety of operating systems including Windows95.RTM. and Windows.RTM. 3.11. Version 2.X of RP5 is a 32-bit application that runs on Windows95.RTM. and Windows.RTM. NT. The 2.X version of RP5 is preferred, since it has an improved user interface and image processing enhancements, including JPEG compression. A preferred hardware configuration for the referring physician station 49 comprises a Dell PC with a Pentium Pro 200 MHz processor, Windows.RTM. NT operating system, 64 mega-bytes of RAM, 3.1 giga-byte hard drive, 12X CD-ROM, and 33.6 KHz modem. The referring physician station may be connected to the PACS core components, in particular to the network gateway, via any type of network connection; although ISDN network connections are preferred for teleradiology applications. In preferred embodiments of the invention, the referring physician station is not a client of database server 2, but rather includes its own database. In operation, the referring physician station uses RP5 to request and retrieve studies on the PACS. These studies are then displayed on the station. In general, the PACS only sends to the referring physician station studies or, alternatively, summaries of studies that are simplified and/or JPEG compressed. That is, in general, the referring physician station does not transmit studies back to the PACS; although RP5 can be configured to do so if this functionality is desired. 1.6.4 Clinical Station Clinical stations are loaded with CS500 software, and generally comprise single monitor workstations designed for use by clinicians and referring physicians, and for home/office use (as opposed to primary viewing). CS500 software comprises PC-based DICOM "query/retrieve/display/report/print " software which can be loaded onto any suitably equipped workstation. CS500 has all of the functionality of the RP5 software described above, with the addition of split screen comparison of two (or more) studies, selectable inverse video, auto-pilot processes, enhanced DICOM printing tools, and login security similar to the PACS itself. Other features include linear and angular measurements of study images, balloon help tips, and support for 1280.times.1024 dpi and higher display resolutions. A preferred hardware configuration for clinical station 50 comprises a Dell PC with a Pentium Pro 233 MHz processor, Windows.RTM. NT operating system (although Windows95.RTM. may be used), 64 mega-bytes of RAM, 3.1 giga-byte hard drive, 24X CD-ROM, 33.6 KHz modem, and 10/100 MB Ethernet connection. As above, the clinical station may be connected to the PACS core components, in particular to the network gateway, via any type of network connection; although ISDN network connections are preferred for teleradiology applications. In preferred embodiments of the invention, the clinical station is not a client of database server 2, but rather includes its own database. It does, however, inherit the login names and security profiles from the PACS to which it is networked. In operation, the clinical station uses CS500 to request and retrieve studies on the PACS. These studies are then displayed on the clinical station. In general, the PACS only sends to the clinical station studies or, alternatively, summaries of studies that are simplified and/or JPEG compressed. That is, in general, the clinical station does not transmit studies back to the PACS; although CS500 can be configured to do so if this functionality is desired. 1.6.5 Transmit Station Transmit station 51 comprises a computerized scanner which scans in film, in particular radiographic film such as X-rays, and which transmits the scanned film images to the PACS (specifically, to the network gateway) via a network (i.e., LAN/WAN) connection. In this respect, the transmit station operates in roughly the same manner as any other imaging modality on the PACS. The scanned images are transmitted to the PACS using DICOM 3.0 protocol, and may be compressed using JPEG prior to transmission. In preferred embodiments of the invention, the transmit station also organizes scanned images into patient folders (comprised of one or more studies) prior to their transmission, and can retrieve and display RIS reports from the PACS in cases where there is a PACS broker extension present. In preferred embodiments of the invention, the transmit station is comprised of a film digitizer and a Pentium Pro PC running Windows.RTM. NT 4.1. The film digitizer is preferably capable of scanning film ranging from 8".times.10" to 14".times.17". Different scanning resolutions also may be provided, i.e., 512.times.512 through 2048.times.2048, together with the ability to view and rotate digitized images prior to transmission. 1.6.6 Medical Gateway Generally speaking, a medical gateway is a programmable secondary capture device for non-DICOM 3.0 imaging modalities and output devices. The medical gateway is used to provide connectivity between these modalities/devices and the PACS. To this end, medical gateways communicate with the core PACS components via APIP, or its equivalent. In general, each medical gateway can support up to three imaging modalities or output devices, as shown, e.g., in FIG. 1. That is, in the figure, medical gateway 52 ("MG") is interposed between the PACS core components and two imaging modalities 54, and medical gateway 56 is interposed between the PACS core components and printer 58 in the printer network. In preferred embodiments of the invention, these medical gateways are PCs that are TCP/IP-ready, and that have IP routing capabilities. 1.6.7 Printers Various DICOM-compliant printers may be connected to the PACS, as shown in FIG. 1. These printers are typically connected to the network gateway via a TCP/IP network connection; although other network connections are possible. Examples of two such printers are the Drystar.RTM. 2000 Thermal Printer and the Drystar.RTM. 3000 Thermal Printer, both of which provide at least 300 dpi in resolution. 2.0 Routing As described above, the PACS receives studies from one or more sources. Each of these studies is routed by network gateway 6 to one or more of the stations described above in section 1, or alternatively to an output device such as a Web server or printer. To effect this routing, the network gateway executes PACS software modules in order to receive the images, to determine where on the PACS that each study/image should be routed based on predetermined routing rules, and to route the studies directly to the appropriate location automatically. In more detail, network gateway 6 routes studies directly to a station, such as a reviewing station, an archive station, a referring physician station, a clinical station, etc., or directly to another location on the DICOM network, such as a Web server or a printer (if available), based on routing rules defined by a combination of one or more of the routing attributes set forth below in Table 3.
TABLE 3
Routing Attributes
RIS
Attribute Function Gateway?
Acquiring The acquiring station is the imaging modality No
Station that sends studies to the PACS. The simplest
routing scheme is one that sends all studies
from one acquiring station to one or more
reviewing stations.
Radiology The PACS administrator designates certain Yes
Specialty reviewing stations for reading studies
related to certain specialties (e.g., head,
abdomen, pediatrics). All such studies
are routed thereto.
Patient The RIS maintains a list of patient locations Yes
Location that is essentially a road-map to each bed
in the hospital. Reviewing stations are located
in a physical space that maps to some patient
location number. For example, it is possible
to create routes to trauma centers, ICU, and
emergency rooms using the patient location
as the routing criteria. Patient location routes
support wildcards (e.g., "trauma !").
Referring The RIS maintains a list of referring physician Yes
Physician names, and assigns code numbers to the names.
Referring physician routes support wild cards.
Time A section called "Off Peak Schedules" No
allows the user to configure time ranges
for use as routing criteria. For example,
a route could be configured to send studies
to a station where an on-call physician
is seated during evening hours. Another
example might be to route studies to a
physician's home after-hours or on weekends.
Study Routing may be configured so that studies are Yes
Status sent to certain locations based on a change
in study status. For example, the user
may delay transmission of studies to
clinician stations until a report
has been generated.
Pre-fetch Selected stations may he configured as Yes
Rules "pre-fetching" targets, while
others may be excluded from pre-fetching.
Of course, the invention is not limited to routing images based on the attributes set forth in Table 3. Other attributes also may be used as well. FIG. 4 shows the routing system of the present invention. More specifically, as shown, an imaging modality 60 or, alternatively, PACS broker 46, transmits a study to network gateway 6. Network gateway 6 then executes code to determine, in step 61, if the study is broken, meaning that it has demographic data that is incorrect in that is conflicts with information already contained on the PACS. In this regard, as noted above in section 1.3, the network gateway maintains study demographic information for validation purposes. This is the information used to determine whether a study is broken. In the event that the study is broken, the network gateway executes code in step 62 to store the study in its private cache, from which the PACS administrator may "fix" the broken study in step 64. Studies that are fixed, or that are not broken, are routed to appropriate PACS (e.g., reviewing) stations using routing rules, as shown in step 65. These routing rules may be created by the user, as described below. To this end, a service button in the PACS user interface (see section 3.1 below) displays a service menu "Web tool" in response to clicking on a service action button. A representative example of the service menu "Web tool" is shown in FIG. 5. As shown, this service menu contains various "Installation" hyperlinks written in HTML which provide information regarding software used on the PACS (specifically, the Solaris.RTM. operating system, device EEPROM parameters, system variables, installation parameters, an installation log, and Solaris.RTM. and other software packages), and information regarding hardware used on the PACS (specifically, the system configuration, the system date and time, and tape drive information). Of interest with respect to routing, are the hyperlinks listed under "Configuration". These hyperlinks include DICOM network link 66, routing patterns link 67, referring physician link 69, patient location link 70, radiology specialty matching link 71, radiology specialties link 72, external specialty matching link 74, and external specialties link 75. In brief, these links allow a user to input information at the user's station, which information is then transmitted to the network gateway. The network gateway takes this information and generates (or updates) routing rules. Starting with DICOM network link 66, this link connects to a site which displays a form which allows the user to set various PACS stations as potential recipients of routed studies. A representative example of this form is shown in FIG. 6. As shown, the form lists various PACS stations. In preferred embodiments of the invention, the user may input a "D" (for designation) next to a PACS station to indicate that the station is a destination (i.e., that it is a potential recipient), or a "T" (for transmit) next to a station to indicate that the station is a transmitting station. Obvious examples of destination and transmitting stations are reviewing stations and imaging modalities, respectively. Acquisition stations link 76 connects to a site which displays a form which may be used to assign a routing name to each imaging modality, and to provide other information regarding the imaging modality to the PACS. An example of this form is shown in FIG. 7. The form includes add button 78, delete button 79, and modify button 80, together with table 81. Add button 78 is used to add the information in the form to the PACS, delete button 79 is used to delete the information in the form from the PACS, and modify button 80 is used to modify the entries in table 8 manually. Table 81 includes station name box 82 for assigning an alias to the imaging modality (i.e., an acquisition station), modality box 84 for inputting the modality's type, OCR box 85 for selecting whether the station is a direct-capture device that outputs images requiring OCR, field mapping box 86 for inputting whether the modality requires DICOM mapping of an accession number or patient ID, HIS verify box 87 for setting the station as an HIS verified source, film mode box 89 for use with studies captured on film, routing pattern box 90 for inputting a routing pattern associated with the modality, need-to-archive box 91 for performing selective archiving of images output the imaging modality, demographic layout box 92 for creating names associated with demographic layouts provided for images produced by the modality, and accession number box 94 for entering an accession number associated with a study produced by the imaging modality. Returning to FIG. 5, routing patterns link 67 displays a form on which a user may create routing rules and assign a set of attributes to each routing rule. The names of these routing rules may then be input to the acquisition station form described above. In more detail, clicking on link 67 connects to a site which displays the form shown in FIG. 8. This form includes add routing pattern button 95, delete routing pattern button 96, modify routing pattern button 97, and table 99. Add routing pattern button 95 adds the routing rule set forth in the table to the network gateway; delete routing pattern button 96 deletes the routing rule from the network gateway; and modify routing pattern button 97 allows the user to modify the routing rule. Table 99 includes name entry line 100 for assigning a name to the routing rule; destination entry line 101 for selecting a station to which studies will be routed by the rule; specialty entry line 102 for inputting a specialty (e.g., pediatrics, CR chest, CT abdomen, etc. or "Don't Care") which will invoke the routing rule; study status entry line 103 for inputting a minimum study status (e.g., new, dictated, preliminary, approved) which will invoke the routing rule; referring physician entry line 104 for inputting a referring physician to which the routing rule will apply; "apply routing to" entry line 105 for inputting a category of studies (e.g., "all" or "pre-fetched") to which the routing rule will apply; and "off peak schedule name" entry line 107 for selecting an off-peak time, such as weekdays, weekends or weeknights, during which the routing rule is to apply. Other entry lines which may be included in table 99 are a patient location entry line for routing based on patient location, and an arrival time entry line which is a variation of "off peak schedule name" entry line 107. FIG. 9 shows another example of a form for creating routing rules, which includes some, but not all, of the features described above Returning to FIG. 5, referring physician link 69 and patient location link 70 provide the user with separate libraries of potential referring physicians and patient locations for the PACS. For example, FIG. 10 shows a page which includes a list of potential patient locations, which can be accessed via patient location link 70. As shown in the figure, this page includes the abilities to add patient locations (add location button 109), to modify existing locations (modify location button 110), and to delete locations (delete locations button 111). A page which includes a list of potential referring physicians is substantially similar to that shown in FIG. 10, and is therefore omitted herein for the sake of brevity. Radiology specialty matching link 71 and external specialty matching link 74 map RIS procedure codes to these specialties, thereby enabling organ-based routing (i.e., routing studies to reviewing stations based on bodily organs that the images therein depict). In this regard, each procedure performed on an organ is identified by an RIS procedure code. The present invention maps these RIS procedure codes to the above specialties. Then, when routing is performed based on a radiology specialty (e.g., MR, CT, etc.) or on an external specialty (e.g., pediatrics, emergency room, trauma centers, and orthopedics, etc.), organ-based routing is performed as well. 2.1 Pre-fetching The present invention includes the ability to route relevant prior studies to a reviewing station in contemplation of a scheduled event, such as a patient examination or the like. This process is called pre-fetching, and is effected by code executing on the network gateway. In more detail, pre-fetching involves RIS gateway 46 receiving information concerning a scheduled event from RIS 44, and then transmitting that information to the PACS, in particular to network gateway 6 (see FIG. 1). The network gateway then queries the RIS, via the RIS gateway, requesting details concerning the scheduled event. For example, the network gateway can request information concerning the nature of the scheduled event (e.g., an exam, consultation, surgery, etc.), the time and date of the scheduled event, and the body part pertaining to the scheduled event, among other things. Once the network gateway receives the requested information from the RIS, predetermined PACS pre-fetching rules stored in memory on the network gateway take over to retrieve relevant prior studies from a memory (e.g., the archive) on the PACS. These pre-fetching rules may be set/modified by the user via relevant prior rules link 112 on the form shown in FIG. 5, as described below. Initially, the pre-fetching rules are used to determine which prior studies on the PACS should be retrieved. Once this is done, the prior studies are copied into the archive station's cache (or, alternatively, the network gateway's cache) and routed to the appropriate stations automatically. In cases where a recipient station is cache-less (e.g., a cache-less reviewing station), the network gateway will merely copy the relevant prior studies to cache without routing them automatically. That is, in this case, the network gateway waits for a request from a PACS station before routing retrieved images thereto. Of course, the behavior of the network gateway is dictated by the applicable pre-fetching rules (together with the details received from the RIS). In this regard, as noted above, the pre-fetching rules may be set and/or modified by the user via relevant prior rules link 112. More specifically, clicking on relevant prior rules link 112 connects the user to a site which contains a form used for inputting information to add, delete and/or modify pre-fetching rules. Once this information is input into the form, the information is conveyed back to network gateway 6, which generates pre-fetching rules therefrom, stores these rules in memory, and executes them as required. An example of this form is shown in FIG. 11. This form includes add button 114 for adding the pre-fetching rule defined by table 115, delete button 116 for deleting the pre-fetching rule, and modify button 117 for modifying the pre-fetching rule. Representative pre-fetching rules are shown in FIG. 11, and are set forth below in Table 4.
TABLE 4
Pre-fetching Rules
Available
Rule Choices What it Does
Radiology All internal Allows the user to selectively configure pre-
Specialty and external fetching of images relating to particular
specialties specialties.
Modality All Allows the user to selectively configure pre-
modalities in fetching of images generated from particular
the PACS imaging modalities.
Fetch Yes/No Looks at the speciality of a new study
Same and does or does not, pre-fetch prior
Specialty studies comprising the same specialty.
Fetch Yes/No Looks at the modality that created a new study
Same and does, or does not, pre-fetch prior studies
Modality created by that modality.
Maximum Enter Indicates the maximum number of studies that
Number Whole can be pre-fetched.
of Studies Number
Oldest Enter Indicates that only studies captured after a
Study to Whole predetermined date will be pre-fetched.
Fetch Number
In Years
Fetch Yes/No Fetches relevant prior studies' summaries along
Summary with the studies themselves (if present).
Fetch Yes/No Fetches relevant prior studies' summaries, but
Only not the studies themselves.
Summary
Route Yes/No Indicates whether, after the studies have been
Priors copied to archive cache, they are to follow the
routing rules configured above.
Cache Yes/No Indicates whether retrieved studies are
Priors to remain in the archive's cache,
from which they can be retrieved.
Of course, it should be noted that the invention is not limited to the pre-fetching rules shown above, and that any others may be incorporated herein. Moreover, the foregoing pre-fetching rules can be combined, where appropriate, as desired. 3.0 User Interface The main study window (alternately, the study management window) is the primary user interface for each of the above-described PACS stations (both core components and extensions, where appropriate). The main study window is implemented and controlled by PACS software modules running on each PACS station. As shown in FIG. 12, the main study window includes a main study list 116, system status indicators 117, and two sets of action buttons 118 and 119. Action buttons 119 enable a user to view, retrieve, transmit, and delete studies. These buttons also allow a user to perform administrative functions and exit the system. Action buttons 118 allow a user to sort patient studies by modality, creation time, patient name, and other criteria. These buttons also permit users to select, restore and save worklists. Which of action buttons 118 and 119 are available in the main study window depends, at least in part, upon settings in the user's profile, as described in more detail below. The PACS administrator, however, can limit the action buttons available to particular users and to particular stations, regardless of the settings in that users's profile. Status indicators 117 provide information about the PACS. In brief, left-most segment 120 displays an amount of available local memory. Its color changes from green to amber to red as the local memory fills. Second segment 121 displays system activity levels during a retrieve operation. The retrieve queue of the station can be viewed by pointing and clicking to this segment. Third segment 122 displays system activity levels during study transmission. Fourth segment 123 indicates that there are pending off-line jobs for MODs not physically present in the jukebox. This segment is usually provided on archive stations only; although this is not a requirement. Fifth segment 124 indicates if there are any "broken" studies in the station's private cache. This segment is usually provided on the network gateway and the archive stations only; although this is also not a requirement. 3.1 Action Buttons When the user clicks on an action button in the main study window, the PACS (specifically, the PACS software on the station) carries out an action, usually with respect to a selected study or studies. The following is a description of the various action buttons that may be provided in the main study window, and the processes associated therewith. Display button 125 enables a user to display one or more selected studies in the main study list simply by clicking on the button. Specifically, in response to a user clicking on this button, the PACS software retrieves selected studies from the station's cache, and then displays the selected studies on the station's display screen. Display button 125 also initiates "pipeline" retrieval of images described below in section 6.0. In preferred embodiments of the invention, display button 125 is found on reviewing stations only. However, other embodiments of the invention also provide it on one or more of the archive station, the database server, and the network gateway, as well. Retrieve button 126 enables a user to retrieve one or more selected studies. More specifically, in response to a user clicking on this button, the PACS retrieves selected studies into the user station's cache, usually prior to display. In this case, the PACS software usually retrieves studies from the archive station. Transmit button 127 enables a user to transmit one or more selected studies from local cache on the user's station to another PACS station. To this end, in response to a user clicking on button 127, the PACS software displays a dialog box (not shown), in which the user may specify the location of a receiving PACS station or the like, as well as other relevant parameters. As noted above, the PACS puts limitations on where studies, particularly edited studies, can be stored. These limitations generally cannot be circumvented via transmit button 127. Merge button 129 merges two or more selected studies with matching patient IDs, accession numbers, and/or study IDs into one study folder. Thereafter, the study folder is treated by the PACS as a single study, meaning that it is transmitted, routed and received as if it were a single study. In order to merge studies-, they should remain in a station's cache, and off the archive's jukebox. In preferred embodiments of the invention, the merge button is provided on the archive station and the network gateway only; however, other embodiments may include it on all or some of the other stations. Split button 130 splits a folder of studies. Splitting is a process whereby images are removed from one study and pasted into the folder of another study. It is most often used to split folders which include studies that have been unintentionally combined (e.g., studies of different patients). This can occur in some imaging modalities where the technician fails to close an exam before starting another. A folder should be stored in a station's cache, and off the jukebox, before it is split. In preferred embodiments of the invention, the split button is provided on the archive station and the network gateway only; however, other embodiments may include it on all or some of the other stations. Delete button 131 deletes one or more selected studies from a station's cache. This button is preferably provided on all PACS stations; however, it is most often used on the reviewing stations to delete studies that have been reviewed. In the event that a selected study is the only copy of that study on the entire PACS, the PACS software will issue a warning indicating that the user is deleting the last copy of that study on the system and will request confirmation before the study is actually deleted. Print button 132 prints a selected study, series of images, or individual image based on printer settings for the station. The copy of the study in the station's cache is the copy that is typically printed; although the invention can be configured to retrieve a "new" copy of the study from the archive or elsewhere and print that new copy. Preferred embodiments of the invention also provide a user with printer options, provided that there is more than one printer connected to the PACS. Examples of printers that are compatible with the PACS are provided in section 1.6.7 above. As noted above, certain studies may be protected from auto-deletion by assigning them a protected (or "P") status. Protect button 134 effects this operation on one or more selected studies. Studies may be protected on any of the PACS stations described above. An indication that a study is protected is provided in the main study list and worklist, as described in more detail below in section 3.2. Show Report button 135 permits a user to retrieve, and to display on his station, a patient report from the HIS or RIS. As described above, in order to obtain information from the HIS or RIS, a PACS broker (i.e., RIS gateway 46) is typically required on the PACS. Accordingly, the show report button is generally only included in PACS that include a PACS broker. Of course, the show report button may also be used in cases where the PACS is connected to the HIS/RIS via means other than a PACS broker. Study information button 136 displays a form relating to one or more selected studies. This form includes information about the studies and/or about the patient associated with the studies. In preferred embodiments of the invention, the user is able to set, in advance, the format of the form and the patient and/or study information that is to be included in the form. FIG. 13 shows a representative example of the study information form displayed by button 136. As shown, study information form 137 includes entries for patient ID, name, sex, location, study ID, date, time, station, accession number, procedure, modality, physician, reported status, study status, specialty, private field, comments, reason, and keywords (user-assigned word(s) for identifying a study quickly from a list of studies). Also included in the form are action buttons. In this regard, button 139 saves comments and changes to the patient study information; button 140 closes the study information window; and button 141 performs RIS validation, meaning that it inserts the actual patient ID and accession number into the study. In this regard, in trauma cases in particular, a study may be forced into the PACS without going through RIS validation. When this is done, the invention inserts a UID (i.e., "unidentified") string for the patient ID. Button 141 thus substitutes the patient's ID for the UID string. Returning to FIG. 12, process monitor button 143 enables a user to monitor and to change the status of archive, gateway, print and transmit jobs stored in PACS stations caches. In brief, as noted above, and as described below in section 3.2, each study in the main study list and worklist has a status associated therewith. In response to a user clicking on process monitor button 143, the PACS software displays a form containing the status of one or more selected studies, preferably, on any of the stations in the PACS. This form can then be edited to alter jobs' status or the like. The process monitor is described in greater detail below in section 4.2.1. An archive administration button, shown in FIG. 14, can also be included in the main study window. The archive administration button permits a user to prepare, import and export MODs for the archive station's jukebox. In preferred embodiments of the invention, this button is provided only in the main study window of the archive station; although this is not a requirement. FIG. 14 also shows a form that the PACS software displays in response to a user clicking on button 144. This form include two rows of action buttons. The top row of action buttons is always active, while the bottom row of action buttons becomes active only after an archive process has been halted. With respect to the top row of action buttons in form 145, this row contains button 146 which interrupts all archiving activity. That is, after this button is activated, stored and retrieved jobs will continue to enter the appropriate queues, but will not be acted upon until the archive process is up and running again. Button 147 re-starts the archive process so that all pending retrieved and stored jobs can be processed; button 148 allows a user, after selecting one optical disk from volume list 149, to view a form (not shown) that lists the study ID, study date, and number of pages of selected studies on a disk; button 150 refreshes the form shown in FIG. 14; and button 151 exits the archive process. With respect to the bottom row of buttons in form 145, button 152 starts a recovery process whereby the station checks all of the disk locations inside the jukebox; button 154 imports a new optical disk into the jukebox and assigns it a volume ID; button 155 moves a disk to an import/export element at the top of the jukebox; button 156 erases the contents of any optical disk that is not hard-wired protected; button 157 formats a fresh optical disk so that it can be imported; button 159 performs a quick check of the jukebox disks to ensure that each is inserted in its correct slot; and button 160 ejects disks from the drives and returns them to their appropriate mail slots. Status indicators in form 45 indicate whether a disk is Fresh, meaning that it has not yet been written to; Open, meaning that it has room for more studies; Closed, meaning that it is filled; Protected, meaning that it may not be erased; or Foreign, meaning that it was created on a different PACS archive. Returning to FIG. 12, as noted above, the invention provides a way to customize the main study window and display tool bar based on information input to a user profile form and/or an access control form. Users button 161 displays these forms, shown in FIGS. 31 and 30, respectively. Section 5.0 below describes, in detail, customizing the main study window and tool bar using these forms. A backup button (not shown) may also be provided in the main study window to initiate backup of the PACS database. This usually means storing the PACS database to DLT or, alternatively, MOD. In preferred embodiments of the invention, this button is provided on the database server station only; however, other embodiments of the invention provide it on other stations as well. Fix study button 162 calls up a "fixup" GUI which enables a user to modify or to alter information relating to broken studies. As noted above, a broken study is a study with demographic data that is incorrect or that conflicts with information already contained on the PACS. A broken study can be detected in the main study window based on an indicator (not shown) appearing to the right thereof. Such studies typically remain in the network gateway and are not available to reviewing stations; hence button 162 is usually provided only on the network gateway. In response to a user clicking on button 162, the PACS software displays fixup GUI 164, shown in FIG. 15. GUI 164 displays the information pertaining to the broken study, and allows the user to correct incorrect information. To this end, the fixup GUI 164 includes action buttons, which buttons include button 165 for clearing the original study information, button 166 for restoring cleared study information, button 167 for testing newly-input study information to determine whether the study has been "fixed", button 168 for forcing the study into the public cache once it is determined that the study has been fixed, button 169 for viewing the study, and button 170 for closing the GUI. A similar form may also be provided on the RIS gateway to fix broken studies received from the RIS. HIS window button 171 permits a user to open a "telnet" session between the PACS and the HIS/RIS via the PACS broker, database server, and network gateway. During this telnet session, the user may view requested patient information and RIS events, preferably in real-time. This button is typically provided on the reviewing stations, but may be available on other PACS stations as well. Service/configure button 172 is used by the PACS administrator to set up the PACS and all network gateway functions, including the routing and pre-fetching rules described above in section 2. The service button is also used to check the capacity of caches in the various PACS stations using installed service tools. Sign off button 174 closes the PACS application and places the user at a login screen. The user may re-enter the PACS by entering both a user login ID and a password. Custom query button 175 enables a user to query for patient images, studies and/or folders on the PACS. When activated, the custom query button displays a form, which the user may fill out in order to specify attributes of images, studies and/or folders stored on the PACS that the user wants to retrieve. FIG. 16 depicts the form displayed by clicking on custom query button 175. On this form, the user may enter a range of search dates, times, patient information, RIS procedure codes, or other relevant information on which to base the custom query. Similarly, the user may initiate location sorting by activating location sorting button 178; status sorting by activating status sorting button 177, and modality sorting by activating modality sorting button 176. The sorting effected by these buttons is substantially identical to that described below. Once the relevant information has been set in custom query form, searching may be initiated by clicking on search button 179. Thereafter, images, studies and/or folders which match the search criteria are retrieved and displayed in the study list. Clear search criteria button 180 is also provided in the custom query form to clear existing entries, and exits close button 181 from the custom searching function. Returning to FIG. 12, default query button 182 applies default sort and select criteria for the user based on the user's login ID. This default criteria may be specified, and subsequently changed, by altering the user's profile. This may be done at login, or at any point during execution of the PACS. Worklist select button 184 selects studies that match default worklist criteria set forth in the user's profile. For example, this button may be configured, via the user profile, to select all CT NEURO (i.e., computed tomography neurological) studies from the main study list. The button may be configured to select relevant prior studies as well, as described below. Save worklist button 185 permits a user to save selected studies as a worklist. This save operation saves the worklist over station power cycles and user logouts. Restore saved worklist button 186 restores a worklist that was saved previously. Location sorting button 187 permits a user to display a list of all studies residing at a particular location in the PACS. Clicking on location sorting button displays a pull-down menu which includes a list of optional searching locations. These locations include "Local" (which is shown), which displays a list comprised only of studies contained on the station's local storage (e.g., its cache); "System", which displays a list comprised only of studies on the PACS; and "Cached", which display a list comprised only of studies that reside on caches within stations in the PACS cluster. An "Other targets" option may also be displayed, by which a user may display a list comprised only of studies at user-specified locations in the PACS. These locations may be specified, e.g., in the access control form described below. Time sorting button 189 permits a user to select and to list studies in the main study list based in their creation date and/or time. More specifically, clicking on time sorting button 189 displays a pull-down menu which includes time-oriented options for sorting through studies in the study list. These options include "Any time" (which is shown), which selects and lists all studies in the main study window regardless of when they were created; "Today", which selects and lists only studies which were created today; "Yesterday", which selects and lists only studies which were created yesterday; and "Last 2, 7, 21", which selects and lists only studies which were created within the specified time period, i.e., 2 days, 7 days, 21 days, etc. In preferred embodiments, the PACS software provides the option of creating a customized "prior days" query by altering parameters in the user profile form. Parameter sorting button 190 enables a user to select and to list studies in the main study list based one or more input parameters. Specifically, clicking on parameter sorting button 190 displays a pull-down menu which includes the following sorting options: "patient name", "patient ID", "accession number", "patient location", "radiology specialty", "referring physician", "private field" (i.e., a user-specified field), and "unspecified" (no sorting--this is shown). The user may then select one of the foregoing options for searching through the study list. Once an option has been selected, the user specifies an entry in box 191 which corresponds to the specified field. For example, if the "accession number" option is selected from the pull-down menu, the user may enter an accession number into box 191. "Wild cards" can be entered into box 191 to enhance functionality. The PACS software then searches for the specified study or studies, and selects and lists only those studies in the main study window. List ordering button 192 permits a user to reorder a list of studies in the main study list based on parameters provided in a pull-down menu. Specifically, clicking on list ordering button 192 displays a pull-down menu which includes the following options: "Recent last", "Recent first" (which is shown), and "Name". "Recent last" reorders the study list in chronological order. "Recent last" reorders the study list in reverse chronological order. "Name" reorders the study list alphabetically by name. Other options, of course, may be provided as well. Modality sorting button 194 permits a user to select and to list studies in the main study list based on the imaging modality used to generate images in the studies. More specifically, clicking on modality sorting button 194 displays a pull-down menu which includes modality-oriented options for sorting through studies in the study list. These options include "CT", which selects and lists only studies produced by a CT imaging modality and which is shown; "MR", which selects and lists only studies produced by an MRI imaging modality; "US", which selects and lists only studies produced by a US imaging modality; "CR", which selects and lists only studies produced by a CR imaging modality; "NM", which selects and lists only studies produced by an NM imaging modality; and "Any", which provides no modality sorting. Additional modalities can be added to the pull-down menu by changing parameters in the access control form, as described below. Status sorting button 195 permits a user to select and to list studies in the main study list based on the status of the study. More specifically, as noted above, each study may have a status associated therewith. Up to this point, the only status described has been protected, or "P". However, there are numerous additional status designations that may be associated with each study. At this juncture, suffice it to say that there are at least five additional status designations: new ("N"), dictated ("D"), in the process of being dictated ("d"), reported ("r"), and approved ("R"). Definitions of these (and other) status designations are provided in section 3.2 below. Clicking on status sorting button 195 displays a pull-down menu which includes status-oriented options for sorting through studies in the study list. These options include "new", which selects and lists only new studies; "dictated", which selects and lists only dictated studies or studies in the process of being dictated; "reported", which selects and lists only reported studies; "approved", which selects and lists only approved studies; and "any" (shown), which does not perform status sorting, meaning that all studies remain listed regardless of their status. Of course, this selection list can be modified to select and list studies based on other status designations. Display listing button 196 enables a user to customize the format of the study list. Clicking on display listing button 196 displays a pull-down menu which includes a list of display options. These options include "Study", which displays a list of studies; "Study & Summary", which displays a list of studies and summaries associated with those studies; "Patient & Study", which provides a listing of all studies for each patient, where the patient name is listed only once and all studies are listed line-by-line; and "Patient", which displays studies for a particular patient only. Basic query button 197 initiates searching, sorting and reordering based on criteria set in the pull-down menus of location sorting button 187, time sorting button 189, parameter sorting button 190, list ordering button 192, modality sorting button 194, status sorting button 195, and display listing button 196. That is, after the appropriate criteria are specified via the pull-down menus, the selected criteria are displayed on the main study list. For example, as shown in FIG. 12, modality sorting button 194 is configured to select and list studies from CT imaging modalities. A user then initiates the actual searching/sorting/listing by clicking on basic query button 197. Until this is done, the main study list will not be altered regardless of what has been set via the pull-down menus. Various options are available in connection with basic query button 197. For example, it is possible to cancel a search midway through by double-clicking on basic query button 197. In addition, it is possible to set and to leave the basic query button in the active position. Doing this effectively results in automatic searching/sorting/listing whenever new criteria are set in the pull-down menus. Although not shown in FIG. 12, additional action buttons may also be displayed in the main study window. These additional buttons include a "Copy to Cache" button which copies studies from jukebox MODs to the local hard disk on the archive station; a "Copy to Jukebox" button which copies selected studies from local hard disk or RAID to the jukebox; and a "Configure" button which sets up the PACS network and network gateway functions, sets data staging rules, and checks station cache. The former two buttons are typically provided only on the archive station; although this is not required by the invention. 3.2 Study List Study list 116 contains folders with studies, images and image-related information. Each line in the study list contains information about one study or one patient. Name and column headings are managed through system-wide controls in the access control form. In preferred embodiments of the invention, there are up to 16 fields in the study list. These fields are set forth below in Table 5.
TABLE 5
Study List Fields
Field Definition
Accession The unique ID or job number that is generated
Number by the RIS and that is used to track each
("#") exam (i.e., study), and its corresponding
patient name, date, and exam type.
Patient ID The patient's identification number.
Patient The patient's name, last name followed
Name by first name, with the fields separated by commas.
Modality A two-letter code for the type of imaging
modality that acquired the study (e.g., MR,
CT, US).
Study ID A unique identifier that a modality creates
for each study.
Study The month, day and year that the study was created.
Date
Study The hour, minute and second that the study
Time was created.
Procedure The RIS examination code. This code specifies
the nature of the examination (i.e., the
study description).
Station The station name of the acquiring imaging modality.
# of The number of images for each study or patient.
Images
# of The number of studies associated with each
Studies patient name.
Status The status of each study on the local hard disk (cache).
Patient The RIS patient location field (if present in DICOM).
Location
Radiology The body part that has been mapped to the
Specialty RIS exam code.
Physician The name of the referring physician (if present
in DICOM).
Private May be configured by the user to display
Field another DICOM field.
As noted above, the PACS study list provides information about each study folder in the form of status designations. In cases where the PACS is networked to a RIS that broadcasts changes in study status, the PACS software will automatically update the status designations. Otherwise, the status designations may be changed manually. Each study folder will have one or more of the status designations set forth below in Table 6.
TABLE 6
Status Designations
Status Definition
"C" Cached status, meaning that the study resides
on a station hard disk/RAID somewhere in the
PACS cluster.
"D" Dictated status, meaning that a radiologist has
viewed the study and dictated a preliminary report.
"d" Indicates dictation of a preliminary report is in progress.
"H" Hard copy status, meaning that a printout has been made
of the study. This status indicator preferably remains
with the study always.
"I" Indicates additional study comments in a study
"Info" form.
"L" Local status, meaning the study is contained in memory
on the local hard disk. In preferred embodiments
of the invention, only local studies may be viewed,
printed and transmitted.
"l" Indicates that the study is in the process of being
transmitted to this destination. This changes to
an "L" once the study is received.
Studies with an "l" status may be viewed
via the pipelining process described below.
"M" Indicates that the study has been archived to a MOD.
"m" Indicates that only part of a study has been archived.
This generally means that there are configuration
problems with the PACS routing rules or that
there is a problem with the archive.
"N" Indicates that the folder is new to the PACS.
"O" Indicates an offline status, meaning that the study
resides in an archive disk that is not
present in the jukebox.
"P" Protected status, meaning that the study
will not be deleted automatically.
"r" Reported status, meaning that a report was created
in the HIS/RIS.
"R" Indicates that a report on the study has been approved.
"T" Indicates that the study resides on DLT.
"V" Indicates that the study has not yet been viewed.
4.0 Image Display Once images have been selected from the main study list, the images may be displayed on a PACS station. Accompanying the display of such images is a toolbar which enables a user to edit, manipulate, and view the images. T | ||||||