Steven C. Horii, MD
As a way of summarizing, let us assume we want to send a CT study from a CT scanner to a workstation and follow how this would be accomplished in DICOM. You or the technologist would interact with software on the CT scanner to set up the particular study to transfer. The scanner might ask you to specify the workstation in addition to the study. This interaction is at the level of the medical imaging application, much of which takes place without DICOM. However, the scanner may store the study in its console in DICOM form, which means that interactions with the scanning application created the DICOM CT information object instances by assigning values entered (eg, patient name, medical record number) and those generated by the scanner itself (eg, date, time, institution, and scanner identification) to the images as they were generated. Thus, asking for a particular study to be sent to a workstation begins by requesting the name or network address of the workstation.
The communication protocol (most commonly TCP/IP) will handle the physical connection to the workstation from the CT scanner. By selecting the function that will send the study, the application software at the CT console begins assembling a series of SOP instances-in this case, CT image storage SOP instances. In our example, one instance will be created for each image to be sent. When the location of the workstation is entered, the DICOM software begins the communication process by requesting an association with the workstation. The communication network will handle the steps preceding this by setting up the communication channel. During the association, the CT scanner will provide its presentation context, telling the workstation that it supports the CT image storage SOP class as a service class user and that this particular application accepts only the verification service class (designed for testing) as a service class provider. The CT software also declares that its transfer syntax is implicit VR little endian. The workstation replies that it supports the CT image storage SOP class as a service class provider and also as a service class user. The workstation replies that it can use implicit VR little endian transfer syntax. Notifications of the acceptance of the association and capabilities are sent back to the respective devices.
The CT software sends the request for storage service along with the images to the software that assembles the DICOM message by putting together the necessary command and data set elements. Next, it sends the message down through the communication stack. The DIMSEs needed for the storage service class and the data set containing the image and other data are handled by the communication stack, where the message will usually be split up into smaller packets to be reassembled into the DICOM message in the communication stack of the workstation. The communication stack detects errors that might occur during transmission and is responsible for getting the packets to the proper location.
The reassembled DICOM message is received by the application layer in the workstation, which uses its software to store the CT images locally. The workstation may also send information (eg, patient name, study type, date of examination, number of images) to other software that will display this information in a worklist.
This lengthy-sounding process is usually accomplished quite rapidly. Typical end-to-end transmission time for CT images might range from less than 1 second to several seconds for each image, depending on the software and communication hardware used. Once the association is established, it can be used for multiple SOP instances, unless the SOP instance was not included in the presentation context list at negotiation. In our preceding illustration, however, the SOP instances containing the CT image object instances can be sent by using the same association once it is established.
<<Previous 1 2 3 4 5 6 7 8 9 Next >>
