DICOM at the first Q8PACS meeting






PACS Project lifecycle

One of the big mistakes hospitals; unfortunately, fall into is considering PACS/RIS as modality. I can count tens of reasons why not to consider PACS/RIS as a modality.

In fact, PACS/RIS are full systems. They are part of the infrastructure of the hospital. They are the backbone !

Thus starting implementation of PACS without planning is another big mistake. Actually, PACS implementation is a project .. No .. No !! It's a huge project indeed.

in VVB (remember! Very Very Basic) we can simplify the whole lifecycle of a project in three phases.


Project LifeCycle

1. Study phase: i.e, study of hospital needs of storage capacity, study of hospital workflow and fetching throughput. I will talk more about the study phase in detail in the next lesson.
2. Design phase: Implementation of PACS on paper by listing all components and spects not biased to any vendor solution.
3. Execution phase: physical implementation on ground by installing agreed on components.


Project Implementation Body

In fact, each project phase is recommended to be implemented by a separate entity. Table below shows implementing body for each phase

Phase
Implementing body
Study
End user / Consultant
Design
Consultant
Execution
Vendor

Note: As far as I know, in all PACS implementations in Kuwait, the three phases where implemented only by a single body "THE VENDOR".. So from that you can deduce how dangerous is this. Vendor's interest is to make optimal profit.


Project Lifecycle -- In Detail

In fact, each phase (of the three above) is a project by itself and each can be divided into five sub-phases.

sub-phase 1. Project Initiation: i.e, forming team, delegating assignment.
       =      2. Planning: i.e., specifying project-phase schedule. Writing down steps to target.
       =      3. Implementation: execution of the phase tasks.
       =      4. Control and follow up: i.e., Quality assurance to make sure that implementation is going on time.
       =      5. Handing over: making sure that tasks where completely done, and to make sure that all requested
                   needed documents were handed over.

Summary
In summary, PACS projects should start buy studying your needs which can be done by either the hospital itself or by a PACS consultant. Design phase is usually implemented by same previous body. Last phase (execution) is implemented by the vendor.

Next Lesson:
Knowing your needs is first project phase.

Lesson(1): DICOM Definition and basic setup

Lesson (1): Dicom

DICOM stands for: Digital Imaging and Communication in Medicine.

In Very..very..basic (VVB) way, we can say that DICOM is a set of rules some people agreed on to make our lives (PACS Admins) easier !! They just wanted to make Medical Image Exchange between modalities, Diagnostic Workstations, and PACS (for example) much much easier.

In fact, most part of DICOM standard talk about how two different DICOM devices when communicating on a network to exchange Medical Images..

DICOM Services

DICOM people tried to summarize medical image exchange (communication) in a limited number of services.

1. DICOM verification 2. Image Store service. 3. Image query/retrieve Service. 4. Image print service. 5. Modality Worklist Service . 6. .... and more and more .... (they are beyound the V.V.B course) .

DICOM Association

Generally any DICOM service will have the following process between to DICOM devices.

a. The device which started the DICOM communication will ask to verify All DICOM services (see UP) b. The other party will reply by listing all DICOM services it supports. c. First device will ask permission to use some service. d. Second device will confirm (yes/no) .. e. First Device will start the service like sending the image data or sending patient information for modality worklist. f. First device have to say END of service when done from (for example) sending all data.

Setup for DICOM Association

In General, You need to set three or Four parameters on (usually) both sides.

1. Destination Hostname (Some times only) 2. Desitnation IP address. 3. Destination Port No. 4. Desitnation Application Entity Title (AET, or AE Title)

1, and 2 are Operating system dependant. 3, and 4 are DICOM software dependant (Modality console, DICOM WS software)

So, a good practice for PACS admins is to keep record of all four parameters in excel sheet in a safe place for futuer reference. Do not allow vendor engineers to choose there own IP addresses. Choose for them your self (If not using Dynamic IP's) Summary In summary, DICOM is a standard made to unify communicatin between medical imaging devices. DICOM is a set of no. of services. To setup a Dicom association between two DICOM devices we need to set four parameter at least on one side. Those parameters are the IP address, Port No. , AE.Title, and some times the hostname.

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.
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.

Mile Stones from my life

MileStones...

1978: Born in Kuwait from a family of three brothers.

1995: Graduated From High School.

1996: Started College at Colorado State University Ft. Collins, Colorado USA.

2000: In July 12th of that year I got married to my beloved lady. She descended from a well know family.. "Albahrani". Their family name shows two possibilities. One, they could be originally from Bahrain, or as people used to call "Shia" from that area as "Bahrani" !!

2001: Graduated with BSc in Electrical Engineering with concentration in Optical Electronics.

OPTICAL ELECTRONICS: Study of Photonic Components (i.e. transmitters, receivers, fiber optics, Imaging Theories, etc..)

Senior Projects:

(1) Measurement of spontaneous emission lifetime in Vertical Cavity surface Emitting lasers (VCSEL)

(2) Numerical Modeling for Vertical Cavity Surface Emitting Lasers.

2001 Professional Career started with Education; Teaching High School Students an Introductory course in IT.

2002 I received my first baby. "Haider" ..one of the names of lion in Arabic and we usually call this name after Imam "Ali ibn Abi Taleb". First Imam and cusin of all mighty prophet.

2004 I recieved my second baby. She is "Fatima" after the name of Lady "Fatima" daughter of all might prophet.

2004 Joined Medical Equipment vendor as Field Service Engineer in Diagnostic Imaging. I'm still in that business but joined other vendors and other lines within radiology.I'm; actually, more into Medical Imaging Information systems.

2007 In September 16, I received my third child. "Zainab" which means "The honor of the father" after the name of daughter of Imam Ali.