Lesson(2): DICOM SOP

Lesson(2): DICOM SOP's Last Time.. We briefly discussed in lesson (1) DICOM and DICOM services and we said that DICOM services are building blocks for any information exchange message. Those services are defined and set by DICOM standard. In other words, any information exchange between two DICOM devices (entityies) can only implemented through those 8 or 10 services. For example, Image Storage, Query/Retrieve, Print, Worklist. See Figure(1) DICOM services

Verification: A service that allows user to check all available DICOM services of the destination. Storage: A service that allows transfer and storage of DICOM images. Query/Retrieve: A service that allows searching for DICOM images of some conidition (like date, name) and then pulling those images from destination. Study Content Notification: Sorry! beyond the scope of VVB course*.

DICOM Modality Work list (DMWL): a Service that provides list of patients to be examined on a DICOM device (modality)

DICOM Modality Performed Procedure Step (MPPS): Sorry! beyond the scope of VVB course*.

Study Storage commitments: Sorry! beyond the scope of VVB course*. Study Result Notification: Sorry! beyond the scope of VVB course*. Basic Print Management: A Service that allows to print medical images on film/paper. . . . and more

Note: These service are of really important role in improving work flow of PACS/RIS we need to consider more of them in the future.

Figure(1): Dicom services in Information exchange

Bad News: Not all DICOM devices and software support all above services.

Conformance Statement Before buying your new modality or DICOM software you need to make sure that it supports all services you need to connect to other moalities, printers, etc.. How ? Using a document called DICOM CONFORMANCE Statment. You can find examples of Dicom Conformance statment on the following site. http://www.gehealthcare.com/usen/interoperability/dicom/index.html We will have a seperate lesson for DICOM conformance in the future. Insha Allah ! DICOM Verification tools Otherwise, if you already have some DICOM device and you want to make sure if it supports some DICOM service you can use DICOM verifivication utilities. You can download some of them at the following URLs.

http://www.charruasoft.com/en/downloads/testscu.zip (539 KB) http://downloads.sourceforge.net/dvt/Dvt_2_3_1.msi (8.2 MB)

DICOM SOP's So far we have spoken only about DICOM services. In fact, DICOM services need to Objects to work on. For Example, when using DICOM image storage service we need to specify "What are we going to store ?" Obviousley some one will say; for example, " I want to store CT Image" ... Yes ! CT Image is the object for the image store servic. So,

SOP = (Service + Object) PAIR

So, objects can be images of type CT, MR, CR, etc.. Or objects can be even things like ECG pattern or Structured reports. Bad News !!! Not all DICOM devices and services support all objects. Information Object Definition (IOD) To be frank the concept of IOD is; again, beyond VVB course. However, I just brought this to show that each object (i.e, CT, MR, etc..) are strictly defined in DICOM standard. Simply, each object will containt image + other information about patient, study, modality, etc.. These information are call DICOM meta data. Information in meta data are stored as an array. Each cell contains a value for some parameter; like, patient name, patient DOB, Study Time, etc.. DICOM Tag Information in meta data are numbered with a number call DICOM Tag. DICOM tag has two numbers: Group and Element. So, if you want to know the patient name from a DICOM file just go to DICOM Tag 0010,0010. Group No is on left and then element no. on right. Example for DICOM tags (See table (1))

0008,0020 StudyDate 0008,0021 SeriesDate 0008,0022 AcquisitionDate 0008,0030 StudyTime 0008,0031 SeriesTime 0010,0010 PatientsName 0010,0020 PatientID 0010,0030 PatientsBirthDate 0010,0032 PatientsBirthTime Table(1): DICOM Tags

So DICOM software/database will always refer to some DICOM tag using the group and element No's. Service Classes (SCU, SCP) Another important concept in DICOM communicatino. In fact, one service in a dicom device can support many objects that's why they call each service a Serivce Class because it can support many SOP's. Furthermore, DICOM standard divided Service classes into two. One is the Service Class User (SCU) and second is the Service Class provider (SCP). On each association (connection) one device will be an SCU, the other will be an SCP. for example, If an MR want to send an image to PACS, PACS will be the party which provides the storage service (SCP), and MR will be the sotrage service user (SCU). Some times, a modality will not support an SOP on both SCU, and SCP. A very clear example of this will be the Print service. Modalities; usually, will only support print as SCU while printer; usually, will only support print as SCP. Bad News !!! Do not assume a modality to support some service as both SCU, and SCP. Check Conformance ! Summary In Summary, when exchanging DICOM info, we are; actually, exchanging DICOM SOP's. Therefore, we should make sure that both DICOM devices support the same Services & Objects. Many DICOM modalities support only some services and some objects too. In other words, a CT scanner usually can not view US images because it doesn't support US object type. Moreover, DICOM devices can be Service users (SCU) or can be service providers per association.