Reporting an event to a peer AE

Retrieval of attribute values from another AE

Requesting another AE to modify attribute values

Requesting another AE to perform an action on its managed DIMSE service Requesting another AE to create a new managed DIMSE service Requesting another AE to delete a managed DIMSE service

FIGURE 3 DICOM storage service class applied to a PACS image acquisition process. An acquisition computer acts as a storage SCU to transmit images to the archive server (storage SCP).
FIGURE 4 Diagram illustrating interprocess communication among the major processes running on the archive server. The symbols are defined in Table 4.

47 Medical Image Archive, Retrieval, and Communication TABLE 4 Processes in the archive server


Description arch Copy images from cache storage to long-term storage; update archive database; notify cache_mgr and arch_ack processes for successful archiving arch_ack Acknowledge acquisition computers for successful archiving; acq_del process at acquisition computers deletes images from local storage image_mgr Process image information; update archive database; notify dcm_send and arch processes pre_fetch Select historical images from archive database; notify retrv process dcm_recv Receive images from acquisition computers; notify image_mgr process (dcm_recv: DICOM Storage SCP)

adt_gw Receive ADT messages from HIS or RIS; notify pre_fetch process retrv Retrieve images from cache or long-term storage; notify dcm_send process dcm_send Send images to destination display workstations (dcm_send: DICOM storage SCU)

cache_mgr Manage cache storage of the archive server qr_server Handle query and retrieve requests from the display process at the display workstations (qr_serven DICOM query/retrieve SCP)

5.4 Image Archiving

Images received in the archive server from various acquisition computers are copied from the archive server's cache storage to the long-term storage device, such as an optical disk library or a DLT tape library, for permanent archiving. These images are stored as standard DICOM image files (see Section 7.1), which can be accessed by display workstations on the PACS communication network.

5.5 Database Updating

Information extracted from the data elements of the images received by the archive server is inserted into the archive database. These data are categorized and stored in different predefined tables, with each table describing only one kind of entity. For example, the patient description table consists of master patient records, which store patient demographics, examination worklist, and correlated studies; the archive index table consists of archive records for individual images; and the study description table consists of study records describing individual medical imaging procedures. These tables provide information necessary for the archive server to perform individual tasks such as file indexing, query and retrieve key search, image routing, and image prefetching.

5.6 Image Retrieving

Image retrieval takes place at the display workstations that are connected to the archive system through the communication network. Retrieval requests are issued to the archive server by the display workstation using DICOM query/retrieve (Q/R) service class via TCP/IP network protocols on a client/server basis. In the retrieval operation, the archive server serves as a Q/ R SCP processing query and retrieval requests it received from the display workstations (Q/R SCU). Requested images are retrieved from the storage subsystem by the archive server and distributed to the destination display workstation with use of DICOM storage service class.

6 HIS/RIS Interfacing and Image Prefetching

A PACS for use in clinical practice cannot operate successfully without an interface to HIS and RIS. This section describes the HIS/RIS interface, and the prefetch mechanism performed by an archive system in PACS with the use of this interface.

6.1 Health Level Seven (HL7) Communication Standard

Health Level Seven (HL7) is an industry standard data interface widely used in many healthcare information systems (e.g., HIS, RIS, PACS) for exchange of textual information [11]. Information exchange among these heterogeneous computer systems takes place over a communication network with the use of TCP/IP protocols on a client/server basis.

By utilizing the HL7 interface, messages, or events, such as patient demographics, ADT (admission, discharge, and transfer), examination scheduling, examination description, and diagnostic reports can be acquired by a PACS from HIS or RIS via a hospital-integrated communication network. Information extracted from these messages can be used by the PACS archive subsystem to perform specific tasks such as the routing (Section 5.2) and stacking (Section 5.3) mechanisms, and the image prefetch mechanism (Section 6.2).

6.2 Prefetch Mechanism

PACS operated in a clinical environment requires fast access to patients' previous and current images in support of online diagnosis. Therefore, the time delay in the retrieval of historical images from a low-speed long-term archive during a clinical review session will discourage the use of the PACS by the physicians. The implementation of a prefetch mechanism can eliminate online image retrieval, which thereby will increase the acceptance of a PACS for clinical use.

The prefetch mechanism is triggered when a PACS archive server detects the arrival of a patient via the ADT message from

HIS or RIS. Selected historical images and relevant diagnostic reports are retrieved from the long-term storage and the archive database. These data are then distributed to the destination display workstation(s) prior to the completion of the patient's current examination. The algorithm of the prefetch mechanism is based on a table lookup process driven by some predefined parameters such as examination type, disease category, location of display workstation, section radiologist, referring physician, and the number and age of the patient's archived images. These parameters are stored in a prefetch table managed by the archive database and will determine which historical images should be retrieved.

There are several factors affecting the operation of a prefetch mechanism:

(a) Storage space of a display workstation capable of stacking the prefetched historical images

(b) Capability of the storage devices in the archive system to handle multiple concurrent retrieval operations

(c) Network capacity to support concurrent transmission of the high-volume images

(d) Capability of a display workstation to receive real-time prefetched historical images with minimal interference to the end users during a clinical review session

All these factors should be taken into consideration when a prefetch mechanism is implemented.

7 DICOM Image Archive Standard

This section describes the archive and retrieval of medical images performed by an archive system using the Q/R service class specified by the DICOM standard.

7.1 Image File Format

Medical images are archived to the storage media as DICOM-formatted files. A DICOM file consists of a file metainformation header and an image information object. The file meta-information header is composed of a 128-byte file preamble, a 4-byte DICOM prefix ("DICM"), and the file meta elements (DICOM group 0002). This file meta-information header contains information that identifies the encapsulated DICOM image data set (Fig. 5).

An archive server receives DICOM images as information objects from the acquisition computers. These images are first encapsulated with the corresponding meta-information headers forming the DICOM files and then archived.

When these archived image files are retrieved from the storage device, only the encapsulated image information object will be extracted from the files, which will then be transmitted to the destinations as information objects.

FIGURE 5 DICOM file format. A DICOM file consists of a file metainformation header and an information object (image data set). The file meta-information header is made of a file preamble, a DICOM prefix, and multiple file meta-elements.

7.2 Query/Retrieve Service Class Operation

A server process running on an archive server controls query and retrieval of the medical images stored in the archive system. This server process takes on the SCP role of the Q/R service class to communicate with the display workstations (Q/R SCU), allowing the latter to query and retrieve images from the archive database and the storage subsystem, respectively.

The Q/R service class is based on the following DIMSE services: C-FIND, C-GET, C-MOVE, and C-STORE. These DIMSE services are described next.

The C-FIND service is invoked by a Q/R SCU to match a series of attribute values, or the search keys (i.e., patient name, examination date, modality type), that the Q/R SCU supplies. The Q/R SCP returns for each match a list of requested attributes and their values.

The C-GET service is invoked by a Q/R SCU to retrieve an information object (i.e., a DICOM image) from a Q/R SCP and transmit the object to the invoking Q/R SCU, based upon the attributes supplied by the latter.

The C-MOVE service is invoked by a Q/R SCU to retrieve an information object (i.e., a DICOM image) from a Q/R SCP and transmit the object to a third-party DIMSE application (i.e., a storage SCP), based upon the attributes supplied by the invoking Q/R SCU.

The C-STORE service is invoked by a storage SCU to request the storage of an information object (i.e., a DICOM image) in the storage SCP computer system. The storage SCP receives the information object from the invoking SCU and stores the object in its storage subsystem.

The following is an example describing how DICOM uses the aforementioned DIMSE services to carry out a Q/R Service Class operation:

Suppose a radiologist at a display workstation queries the image archive system to retrieve a historical MRI examination

FIGURE 6 DICOM query/retrieve operation. The archive server acts as Q/R SCP and storage SCU, whereas the display workstation serves as Q/R SCU and storage ACP. The C-STORE DIMSE service is a suboperation of the C-MOVE DIMSE service in a DICOM query/retrieve operation.

to compare with a current study that is available in the display workstation. To perform this Q/R operation, three DIMSE services, C-FIND, C-MOVE, and C-STORE, are involved. The archive server serves as a Q/R SCP and a Storage SCU, whereas the display workstation serves as a Q/R SCU and a Storage SCP. The following procedures take place in order to complete the operation (Fig. 6):

(a) The Q/R client process (Q/R SCU) at the display workstation requests the Q/R server process (Q/R SCP) at the archive server to establish an association.

(b) The Q/R server process grants the association.

(c) The Q/R client process issues a C-FIND request to query historical examinations belonging to a given patient.

(d) The Q/R server process returns a list of examinations that matches the attribute values supplied by the Q/R client process.

(e) A radiologist at the display workstation selects interesting images from the examination list and issues a C-MOVE service request.

(f) The Q/R server process retrieves requested images from the storage devices and requests the archive server's C-

STORE client process (storage SCU) to transmit the images to the display workstation's C-STORE server process (storage SCP).

(g) The C-STORE client process requests the C-STORE server process to establish an association, waits for the association to be granted, and transmits the images to the C-STORE server process.

(h) Upon successful transmission of the images, the C-STORE client process terminates the storage service class association.

(i) The C-MOVE client process terminates the Q/R service class association.

7.3 Q/R Service Class Support Levels

The Q/R server process at the archive server takes on the SCP role of the Q/R service class by processing the query and retrieval requests based on the information about the attributes defined in a Q/R information model that the image archive system supports. This Q/R information model may be a standard Q/R information model defined in DICOM, or a private Q/R information model defined in the conformance statement of the implemented archive system.

There are three hierarchical Q/R information models defined by DICOM. These are the patient root, study root, and patient/ study only models (Table 5). The following subsections describe these models.

Patient Root Q/R Information Model

The patient root Q/R information model is based upon a four-level hierarchy: Patient, Study, Series, and Image. The Patient level is the top level and contains attributes associated with the patient information entity (IE) of the corresponding image's information object definitions (IODs). Below the Patient level is the Study level, which contains attributes associated with the study IE of the corresponding image's IODs. Below the Study level is the Series level, which contains attributes associated with the series IE of the corresponding image's IODs. The lowest level is the Image level and contains attributes associated with the image IODs.

In each level of the patient root Q/R information model, one attribute of the IE is defined as a unique key attribute that provides access to the associated IE. A Q/R SCU (i.e., Q/R

TABLE 5 Q/R service class information models and their support levels

Was this article helpful?

0 0

Post a comment