Category: DICOM

Query Parameters

in DICOM,

A “normal” DICOM Query, as part of the Query/Retrieve service, is used to ask about the patients, studies, series or images known to a Q/R SCP (normally a PACS). It uses the C-FIND operation (and was originally the only service using that operation, so this query service is often called just C-FIND, despite that fact that the C-FIND operation is also used for other services such as Modality Worklist).

Continue reading..

Radiotherapy Object

in DICOM,

Radiotherapy objects were DICOM’s first foray into non-image Composite Instances - i.e. data to be stored long-term without pixel data. They are stored, handled, retrieved etc. exactly the same way as images. There are 7 radiotherapy objects: Radiotherapy Image Radiotherapy Dose Radiotherapy Structure Set Radiotherapy Plan Radiotherapy Beams Treatment Record Radiotherapy Brachy Treatment record Radiotherapy Treatment Summary All these can of course be handled by DicomObjects, but only the Image and Dose can be displayed in a viewer.

Continue reading..

Relational Queries

in DICOM,

Relational Queries have been in the DICOM standard since the start, but are supported by only about half the PACS in the world. They are negotiated using Extended Negotiation and if requested by the SCU and accepted by the SCP then they remove several of the normal C-FIND rules, namely: It is no longer necessary to quote the unique identifiers for every level above the current query level It is possible to use matching attributes at different levels of the hierarchy e.

Continue reading..

Requirements for StudyUID in Modality Worklist query

in DICOM,


There are strict rules for UID formatting and usage. If these are not followed, then some modality equipment may refuse to accept MWL results containing invalid UIDs. Some of the systems are known to filter out requests for faulty UIDs.

Continue reading..

Retrieving by Accession Number

in DICOM,

We are sometimes asked how to retrieve as study based on the accession number. This is only possible by doing an initial query to find the StudyUID then using those in a retrieval. The explanation is that the DICOM rules allow only the Instance UID, Series UID, Study UID and Patient ID to be used in C-MOVE and C-GET requests. If you wish to retrieve a study based on accession number (or anything else except those 4 identifiers).

Continue reading..

Reverse Role Negotiation

in DICOM,

In the vast majority of Associations, the Association is initiated by the SCU with the SCP responding, but DICOM does allow Reverse Role Negotiation whereby the initiator can request to be regarded as the SCP. In practise, this is only used as part of the Storage Commitment service. An oddity of reverse role negotiation (like Extended Negotiation) is that it is agreed per SOP Class not Per Presentation Context, so an agreement to reverse the roles applies to all presentation contexts using that SOP Class.

Continue reading..

Root & Level

in DICOM,

The ROOT is the overall data model, and there are two main roots in DICOM, STUDY and PATIENT. A third root model also exists called PATIENTSTUDY but it was very rarely used in DICOM and is now officially retired. Within each root structure, operations (find or GET or MOVE) are done at a particular LEVEL. The allowed combinations are: PATIENT Root Allows operations at these levels: PATIENT STUDY SERIES IMAGE STUDY Root Allows these levels:

Continue reading..

SOP Class

in DICOM,

SOP class is one of those horrible obscure expressions used in DICOM which put people off the standard immediately! It is supposed to stand for “Service Object Pair”, and has its roots in the slightly odd object orientated origins of DICOM, but in practice, each object only has one directly associated service (Storage) and each other service only has one type of object, so a better name would be Service OR Object

Continue reading..

Sample Images

in DICOM, Free,

The images below are available for download for use in testing. All are 100% anonymised, and are typical of DICOM images found in the real world Description Modality Download Lateral Chest CR Abdomen (Conventional single slice) CT PA Chest DX Abdomen (Enhanced multi-frame) CT Shoulder (Conventional single slice) MR Cardiac Angiogram XA Endoscopy (MPEG 2) VL Test image (Lego) VL

Continue reading..

Secondary Capture

in DICOM,

Secondary Capture Images Composite Instances which are the “lowest common denominator” images available in DICOM. Whilst there is sufficient information to identify the patient, date and institution, they do not contain any scaling, or other modality information, so are effective “just pictures”. They are commonly used for: Screen captures Scanned request forms etc. Whilst the original secondary capture object definition was minimally defined and originally allowed a huge variety of DICOM bit-depths etc.

Continue reading..

Service Class Roles

in DICOM,

All DICOM network communications occur between an SCP and an SCU SCU is an acronym for “Service Class User” which is the weird DICOM term for a client application. SCP is an acronym for “Service Class Provider” which is the weird DICOM term for a server application. In the vast majority of cases, the Association is initiated by the SCU with the SCP responding, but DICOM does allow Reverse Role Negotiation whereby the initiator can request to be regarded as the SCP.

Continue reading..

Storage Commitment

in DICOM,

Storage Commitment is a DICOM service which allows a creator of images or other Composite Instances to check that they have been stored safely by a server (the SCP) before deleting from its own cache. The images are stored as normal using C-STORE (i.e. Storage Commitment is not used ot transfer the images themselves), but then the SCU sends a storage commitment request in the form of an N-ACTION asking the SCP to report back once the the listed images are safe, which it does asynchronously using N-EVENT-REPORT.

Continue reading..

Store PresentationState into a DicomImage

in DICOM,

PresentationStates are normally saved as external files but sometimes people may want to store them within the associated DicomImage.

Continue reading..

Structured Reporting

in DICOM,

DICOM Structured reports are DICOM SOP Instances, organised just the same way as images etc., but which hold reports rather than images. They are typically therefore only a few kilobytes in size. They contain all the same indexing information as images, and therefore fit into the standard 4 level DICOM Hierarchy, complete with their own “psuedo-modality” of SR. They live with the same study (and therefore have the same Study UID) as the images to which they relate, but as the DICOM rules only allow one modality per series, they (like Presentation States) sit in their own series.

Continue reading..

TCP limitations in DICOM

in DICOM,

DICOM uses TCP (transmission control protocol) as its underlying network transport layer, and despite its widespread and generally successful use around the world for most Internet use, TCP does have some significant limitations. In practice, these limitations are extremely rarely encountered in real life, but they can sometimes be seen in stress test scenarios, and it is then important to to be able to distinguish between those failures which are due to the DICOM application being tested, and those which are intrinsic to TCP itself.

Continue reading..


We use cookies to give you the best possible experience on our website. By continuing to use this website, you agree with our use of cookies. for more information please click HERE