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).
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.
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.
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.
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).
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.
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:
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
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
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.
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.
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.
PresentationStates are normally saved as external files but sometimes people may want to store them within the associated DicomImage.
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.
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.
Providing software toolkits and consultancy for healthcare integration with primary focus on DICOM & XDS
Company Number: 3680043
Founded by Dr. David Harvey
© 2019 Medical Connections Ltd
