Steven C. Horii, MD

The information objects of DICOM are used to communicate the various images and related data between hardware components. However, such information alone is not sufficient to ensure proper operation. When Betty called Acme, she not only communicated information about what was needed but also initiated a series of actions. Betty said she wanted to order 15 widgets. Placing that order (which would likely involve a written purchase order after the telephone call) would start the process of picking the widgets from Acme's stock, moving them to the shipping department, and packing and shipping them. Along the way, there would surely be paper or electronic forms filled out to track progress and inventory changes. In effect, the communication involved a set of services provided by various departments at Acme. If the widgets were to reach your receiving department, it would set off a set of services provided by departments in your company. Thus, in addition to exchanging information (eg, "I want to order 15 widgets," "We have replaced the Mark I Widget with the Mark II Widget"), the communication involved a series of services needed to satisfy your company's request.

Communication of medical imaging information is similar. In addition to communicating with a device, you need that device to do something (eg, workstations display information, printers print it, archives store it). The negotiation process described earlier is a method whereby devices declare what it is they do. DICOM provides standardized services that are used with the information objects. These services are built on a set of elemental services. Because DICOM has both composite and normalized information objects, there are both composite and normalized services. Services are performed using a service element. In our example, a service such as filling a customer's order actually consists of a number of simpler actions or services. Your receptionist answers calls and would direct a call to the sales department if necessary. The salesperson writes up the order and sends a copy to your billing department. All of these are component services of the larger task of filling an order. Similarly, DICOM builds its more complex services out of a set of service elements that are called DICOM message service elements, or DIMSEs (pronounced dim-see). There are five DIMSEs (called DIMSE-C) that are used for composite information objects and six (called DIMSE-N) that are used for normalized information objects. These DIMSEs fall into the categories of operations (such as "store," which would cause data to be stored) and notifications (such as "event report," which would notify a device that something had taken place). These simple DIMSEs are used to build the services that most of us would expect in a picture archiving and communication system. These include services such as "storage," which causes information objects to be stored, and "query-retrieve," which causes a storage device to be queried and information retrieved from it. Some services, such as "storage," have a direct DIMSE counterpart, in which case the DICOM storage service would invoke the DIMSE "store" service. Other DICOM services such as query-retrieve require more than one DIMSE for implementation. The DICOM query-retrieve service makes use of the "find," "get," and "move" DIMSEs.

Because of the object-oriented nature of DICOM, services are actually referred to as service classes. In part, this is because a given service may be applied to a variety (or class) of information objects (eg, storage service class). It is also important to know whether a device provides a service (such as the disk file system on a workstation, which would provide the service of storing images) or uses a service (such as a US machine that would use the storage service on a workstation to store and eventually display images). DICOM refers to descriptions of this behavior as the service role. Devices may be service class providers, service class users, or both. Clearly, these roles need to be understood by the devices in a system if that system is to communicate and operate properly. This is also a part of the negotiation process discussed earlier: The list of capabilities includes not only which service classes are supported but in which roles they function.

<<Previous  1  2  3  4  5  6  7  8  9  Next >>