All notes
Dicom

# DICOM Print

Both server and client component of DCMPRINT support the following DICOM services:

Basic Grayscale Print Management
Basic Color Print Management
Print Jobs
Annotations
Presentation LUT


For SCP:

VerificationSOPClass                       1.2.840.10008.1.1
BasicGrayscalePrintManagementMetaSOPClass  1.2.840.10008.5.1.1.9
BasicColorPrintManagementMetaSOPClass      1.2.840.10008.5.1.1.18
PrintJobSOPClass                           1.2.840.10008.5.1.1.14
BasicAnnotationBoxSOPClass                 1.2.840.10008.5.1.1.15
PresentationLUTSOPClass                    1.2.840.10008.5.1.1.23


SCU:

BasicGrayscalePrintManagementMetaSOPClass  1.2.840.10008.5.1.1.9
BasicColorPrintManagementMetaSOPClass      1.2.840.10008.5.1.1.18
BasicAnnotationBoxSOPClass                 1.2.840.10008.5.1.1.15
PresentationLUTSOPClass                    1.2.840.10008.5.1.1.23


# Note

## Open source projects

• Status a702H is normally an 'out of resources' kind of error.
• There are always ff00H errors when fail to c-get file.
• (0002,0010) UI =LittleEndianImplicit # 18, 1 TransferSyntaxUID
(0008,0016) UI =MRImageStorage # 26, 1 SOPClassUID

The DICOM standard does not support pixel data types other than signed and unsigned integer,
and the maximum bit depth is 16.

"The z spacing is computed from the image position and orientation between two consecutive  slices."
0018,0050 Slice Thickness: 0.6
0020,0032 Image Position (Patient): x\y\z
0020,1041 Slice Location: z

"GDCM - Indeed the value for the spacing of the image could be coming from:"
0018,1164 ImagerPixelSpacing
0018,2010 NominalScannedPixelSpacing
0028,0030 Pixel Spacing: 1.11\1.11
0028,0034 PixelAspectRatio

0028,0102 Hight Bit: 15
0028,0103 Pixel Representation: 0-unsigned,1-signed

0018,5100 Patient Position: HFS = Head First Supine, HFDR = Head First-Decubitus Right, HFDL = Head First-Decubitus Left.


# DICOM concepts

## DICOM

DICOM is known as NEMA standard PS3. So when you find a DICOM PDF with name "PS3.6" then it is the 6th chapter but not 3rd.

DICOM (Digital Imaging and COmmunication in Medicine) is a medical image archiving and communication standard written by American College of Radiology (ACR) and National Electrical Manufacturers Association (NEMA) jointly. Conformance to the standard makes the hospital Picture Archiving and Communication System (PACS) be able to handle with image data from different modalities of different manufacturers. From version 3.0, DICOM adopts the Object-Oriented design, and defines lots of entities and relations (the so called E-R model). Now let's study some concepts in DICOM.

## Presentation Context

Presentation Context (PC) can be considered as a negotiated channel within a DICOM association, through which the application entities exchange data.

A proposed PC consists of: a presentation context ID (an odd in (0, 255], unique within the association), a SOP class, a list of proposed transfer syntaxes. When the peer accepts it, the list of transfer syntaxes is replaced with a single accepted one. Reference.

### Only 128 Presentation context supported?

Dicom.narkive.com (the Google groups actually make a mirror from narkive).

During association negotiation the Presentation Context ID in the Association Request and Association Accept PDUs is encoded in a byte field.

Although its not explicitly stated anywhere in the standard that 127 presentation contexts are allowed, its implied by the fact that the Presentation Context ID is encoded as a byte and must be an odd number.

This was identified as an issue a number of years ago, and DICOM Supplement 90 was developed to address the issue, which can be seen here:

ftp://medical.nema.org/medical/dicom/final/sup90_ft.pdf

Unfortunately, the supplement has not been widely adopted, as far as I know, although I know some of the DICOM toolkits do support it.


The relevant section is in part 8, section 9.3.2.2 in table 9-13:

Presentation-context-ID values shall be odd integers between 1 and 255, encoded as an unsigned binary number. For a complete description of the use of this field see Section 7.1.1.13.


WCF note: Odd intergers between 1 and 255 inclusively, which make a total number of 128 rather than 127. Every persentation context has the format: abstract syntax / transfer syntax.

The key names are "PresentationContext1", "PresentationContext2" etc., in increasing order.  Each list must not contain more than 128 entries, due to the limitation of the DICOM network protocol to 128 presentation contexts per association.


### SCU and SCP's Presentations Context

The following example shows one presentation context list that could be used by an association requestor (Store SCU) to negotiate both lossy-compressed and uncompressed transmission of DICOM ultrasound images.

[StorageSCUJPEGBaselineAndUncompressed]
PresentationContext1 = UltrasoundImageStorage\JPEGBaseline
PresentationContext2 = UltrasoundImageStorage\Uncompressed
PresentationContext3 = UltrasoundMultiframeImageStorage\JPEGBaseline
PresentationContext4 = UltrasoundMultiframeImageStorage\Uncompressed


In the case of an association acceptor (SCP), each SOP class must appear only once in the list. The following example would be a valid transfer syntax list for an SCP, accepting only uncompressed ultrasound images:

[StorageSCPUncompressed]
PresentationContext1 = UltrasoundImageStorage\Uncompressed
PresentationContext2 = UltrasoundMultiframeImageStorage\Uncompressed


## SOP class

Service Object Pair (SOP) stems from odd object orientated origins of DICOM. In practice, each object only has one directly associated service (Storage).

A Service-Object Pair (SOP) Class is defined by the union of an Information Object Definition (IOD) and a DICOM Service Elements (DIMSE). The SOP Class definition contains the rules and semantics which may restrict the use of the services in the DIMSE Service Group or the Attributes of the IOD.

Examples of Service Elements are Store, Get, Find, Move, etc.
Examples of Objects are CT images, MR images, but also include schedule lists, print queues, etc. Reference.

A class defines a certain functionality consisting of a combination of a Service and an Object, which make up the Pair - e.g. CT Storage is an example of an SOP Class.

DICOM has two different types of services, the composite and normalized services. Each SOP class is part of either the composite family or the normalized family. The DIMSE commands are identified as either composite or normalized commands, e.g. C_Get and N_GET. The composite commands operate on objects that are composed of several real world entities. A normalized object, however, consists of a single real world entity. Each DICOM standard SOP Class is identified with a Unique Identifier (UID). These SOP Class UIDs are issued by NEMA so that they can be used by the software that performs the actual negotiation, as well as to specify which SOP class it represents.

It is critical to match up the UIDs between a sender and receiver, because the description of the SOP Classes can be very similar, such as in the case of the new and old versions of some of the SOP classes. The SOP class UIDs specify precisely which standardized DICOM services and objects are being used.Reference.

#### Verification SOP Class

The Verification SOP Class consists of the C-ECHO DIMSE-C service. No associated Information Object Definition is defined. The SOP Class UID shall be "1.2.840.10008.1.1". Reference.

## Composite Instance

Ref. A Composite Instance is the official DICOM term for a persistent storable object. Whilst most composite instances are Images (with pixel data), DICOM has plenty of other Composite Instance types, such as:

• Structured_Reports (SR)
• DICOM SRs are DICOM SOP Instances, organised just the same way as images etc., but which hold reports rather than images.
• 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.
• Key_Image_Notes
• A Object Selection Document can be thought of as a Structured_Report without the report.
• They can be used for multiple purposes where it is required to "group" or "sub-smaple" Composite_Instances.
• There are multiple names by which this object type is commonly known: Key Image note (KIN), Key Object note (KON), KOS.
• They are also used in the IHE XDS-I profile.
• Presentation_States
• A Presentation State is an independent DICOM SOP Instance that contains information on how a particular image should be displayed.
• The Presentation State may contain label information(types of Label and Positions), windowing values, zoom value, scrolling (panning) values, rotations or any other visual display element that is defined within the DICOM standard. However Presentation States contain no Pixel Data as they are intended for use with an existing Dicom Image.
• one Presentation State can be applied to more than one images in the Series.
• Radiotherapy objects were DICOM's first foray into non-image Composite_Instances.
• Only the Image and Dose can be displayed in a viewer. Not that although "Dose" images have pixel data, this is a pseudo-image, showing an intended dose distribution.

## DIMSE

DICOM services use a limited number of basic DICOM operations (officially called DIMSE operations). See this reference for c-get, c-echo, c-move, etc.

• These are "self-contained", and the objects passed therefore contain enough information for the operation to exist independently, without reference to other operations on the same or different associations.

#### Composite operations

• C-STORE
• C-FIND: Initially used as part of the Query/Retrieve service, but subsequently re-used in the Modality_Worklist and General_Purpose_Worklist services, this is a very simple operation rather akin to a SQL query, whereby a dataset is passed from the SCU to the SCP containing 2 sorts of attribute: 1. Those which need to be matched (equivalent to the WHERE clause of SQL) These have "filled in" values. 2. Those to be returned to the SCU (equivalent to the SELECT clause of SQL) These are sent a blank fields.
• C-MOVE
• C-Get: The SCU must know in advance what SOP classes it is to receive over the association, as it must negotiate suitable Presentation_Contexts for them. This information should be obtainable via C-FIND.
• C-ECHO

#### Normalized operations

Normalised Operations: These are themselves akin to simple database operations, and are used a "building block" for more complex services such as printing.

• N-CREATE: This creates a dataset within the SCP for subsequent use. The Instance_UID may be specified by the SCU or if left blank is provided by the SCP.
• N-GET: This requests a single dataset, and requires the Instance_UID of that dataset to be specified in the request. In some cases (e.g. printer status) that UID may be a "Well-known_UID"
• N-SET: This updates a single dataset, and requires the Instance_UID of that dataset to be specified in the request. It is used in printing to "place" the images into the Image_Boxes on the Film_Box and is also used to update the examination status in the Modality_Performed_Procedure_Step_Service.
• N-ACTION: This asks the SCP to "do something". The common uses are printing a film, and checking the status of image storage as part of Storage_Commitment.
• N-DELETE: This asks the SCP to delete a particular object
• N-EVENT-REPORT: This is an unusual operation as it is defined to be sent from an SCP to an SCU. It was initially used for printer updates (e.g. alerting the SCU/user of a film jam), but has subsequently been used in other services such as Storage_Commitment.

## ACSE

• ACSE (Association Control Service Element), defined by OSI, which is used by DICOM to negotiate an Association. The ACSE augments the Presentation Layer Service with Association establishment and termination services.
• For the DICOM point-to-point stack, a minimum subset of ACSE is provided by the Session/Transport/Network Service.
• The communication services are specified in PS 3.8.
• The OSI Basic Reference Model is used to model the interconnection of medical imaging equipment. DICOM uses the OSI Upper Layer Service to separate the exchange of DICOM Messages at the Application Layer from the communication support provided by the lower layers. This OSI Upper Layer Service boundary allows peer Application Entities to establish Associations, transfer Messages and terminate Associations. For this boundary, DICOM has adopted the OSI Standards (Presentation Service augmented by the Association control Service Element). It is a simple service that isolates the DICOM Application Layer from the specific stack of protocols used in the communication support layers.

## Rejection

#### Association Rejection

• Result field (an unsigned binary)
• Rejected Permanent
• Rejected Transient
• Source field (an unsigned binary)
• DICOM UL Service User
• DICOM UL Service Provider (ACSE related function)
• DICOM UL Service Provider (Presentation related function)
• Reason (an unsigned binary)
• For Source "DICOM UL Service User":
• 1 - No Reason Given
• 2 - Application Context Name Not Supported
• 3 - Calling AE Title Not Recognized
• 4-6 - Reserved
• 7 - Called AE Title Not Recognized
• 8-10 - Reserved
• For Source "DICOM UL service provided (ACSE related function)":
• 1 - No Reason Given
• 2 - Protocol Version Not Supported
• For Source "DICOM UL service provided (Presentation related function)":
• 0 - Reserved
• 1 - Temporary Congestion
• 2 - Local Limit Exceeded
• 3-7 - Reserved

#### Contexts Rejection

Contexts Rejection happens during the association negotiation but unlike Association Rejection which kills the association, it rejects some or all the Presentation Contexts proposed by SCU, according to the SCP's own rules.

## DICOM Modality worklist (MWL)

DICOM Modality Worklist is a task manager just like a piece of paper with short text and a check box or the tasks application on your iPhone (or Android). The most obvious benefit WML brings is that there’s no need to reconcile all kind of miss spelled names in the PACS because the patient name is no longer keyed in on the modality workstation but received electronically via the MWL query. The fact that the requested procedure is also received electronically reduces the chance for doing the wrong procedure to the wrong patient. Combined with Modality Performed Procedure step (MPPS), that allows the modality to report the task status, take ownership over the task and checkmark it as done when completed, the up side is obvious.

The most basic abstraction of a task is a short description of what should be done and a checkbox. The MWL data model is a bit more complicated and has two levels.

The top, parent, level is called “Requested Procedure” (RP) and holds the information about the patient (name, id), the study (accession number, study instance UID) and the procedure. The procedure can be described as text using attribute (0032,1060) "Requested Procedure Description" or in a more sophisticated manner using the (0032,1064) "Requested Procedure Code Sequence" where static tables of codes and meanings can be used to configure and maintain procedures in the RIS or HIS.

The child level is called "Scheduled Procedure Step" (SPS) and holds attributes relevant to the modality and the actual procedure to be made. A single requested procedure may hold more than one SPS if the request is for a multi-modality study, for example a chest X-Ray and a CT or whatever combination, or if for example two protocols should be applied (e.g. Chest and Abdomen). As a modality, we will use the data in the RP to identify the patient and eliminate re-typing of the name and ID and the SPS to determine what exactly to do.

The DICOM images that the modality will create should use the attributes received from the MWL. When MWL is implemented, the Study Instance UID is generated in the RIS so if a multi-modality procedure is done, each modality will create a series and attach it to the Study by using the Study Instance UID received in the MWL query.

1. An order is made for an imaging service, let’s say for example a chest X-Ray. The order can be made in various ways. For example it can arrive as a HL7 message from the HIS (Hospital Information System), or it can be that the patient walks in an the order is made at the reception desk.
2. The order is scheduled and assigned to the X-Ray machine or Room that will perform the exam. If there are many X-Ray machines, the order may be assigned to one of them. The assignment is made by setting the AE title on the order and setting a date. The exact way it is done, is very much the business of the worklist manager implementation. DICOM only defines the data model entities. The relevant entity for this is scheduled procedure step. It’s an abstraction of a task with description of what should be done, when it should be done and who should do it.
3. When the X-Ray machine makes a modality worklist query, it gets the list of scheduled tasks and performs them.

## Others

Entity and Relation. In a Object-Oriented world, entity and relation are self-explained. For example, a patient and an image series are both entities, and a patient and his/her own image series are related. In a DICOM diagram, a square box is used to represent an entity while a rhombus box is used to represent a relation.
Object. An object has its own attributes and methods. It is capsulated and can be inherited.
Information Object Definition (IOD) is an abstraction of the information entity. It is what the dicom commands work on.
Service. The functions provided by an object.
Service Object Pair (SOP) is the basic element in DICOM communication, it contains Information Object D (IOD) and (DIMSE).

#### Free UID

This website claims to provide free UID for both software implementations and for image and other objects. The medical connections is a UK based corp.

## DICOMDIR

What is DICOMDIR? Don't confuse it with the directory containing your dcm files, or with the multi-frame dcm file. It is just a file in the root directory in standard DICOM CD/DVD, recording the paths of dicom files on the media.

## UID

• 1.2.840.10008.5.1.4.1.1.7 Secondary Capture Image Storage

## Dicom tag values

### Element types

#### PN, Person Name

Explain the ^ in DOE^JOHN. Elements of type PN (VR - Value Representation, remember) i.e. that their value represent a Person Name follow a notation shared by DICOM and HL7. The ^ is called component separator and it separates the elements of the Person Name which are by order: Family Name^Given Name^Middle Name^Prefix^Suffix. Here are some examples:

Usain Bolt would be “BOLT^USAIN”
President Barak Hussein Obama II would be “Obama^Barak^Hussein^President^II”


### Groups

The groups are organized as follows:

 0000 Command 0008 Identifying 0010 Patient 0018 Acquisition 0020 Relationship 0028 Image Presentation 4000 Text 6000-601E (even) Overlay 7FE0 Pixel Data

### Tags

 Tag Name VR (value representation) 0008, 0052 QueryRetrieveLevel CS (code string, 16 bytes maximum.). Example: study 0010, 0010 PatientName PN (person name, 64 bytes maximum.). 0010, 0020 PatientID LO (long string, 64 bytes maximum.). 0020, 000D StudyInstanceUID UI (unique identifier, 64 bytes max). 0020, 000E SeriesInstanceUID UI (unique identifier, 64 bytes max). 0008, 9205 PixelPresentation COLOR: Image better displayed in color with palette LUT, but displayed in grayscale is also a fallback choice. MONOCHROME: Image better displayed in grayscale. No palette LUT is supplied. MIXED: Used only in enhanced CT/MR image module. TRUECOLOR:. Image should be displayed in color only. 0028, 0002 SamplesPerPixel US (unsigned short). 0028, 0004 PhotometricInterpretation CS (). RGB. MONOCHROME2: grayscale, and 0 is black. MONOCHROME1: grayscale, and 0 is white. Such as in fluoroscopic images. YBR_FULL. YBR_FULL_422. YCbCr color space used in JPEG. 0028, 0006 PlanarConfiguration US. 0: color interlaced, e.g. the data is arranged pixel-wise and then channel-wise. It is default way. 1: color separated, e.g. the data is arranged in color-planes. It is rare but used in RLE compression. 0028, 0008 NumberOfFrames IS. 0028, 0010 Rows US (unsigned short). 0028, 0011 Columns US (unsigned short). 0028, 0100 BitsAllocated US. 0028, 0101 BitsStored US. In some CT, its pixel value is between 0 and 4096, and only 12 bits are enough. The remaining 4 bits may be used for overlay. 0028, 0102 HighBit US. 0028, 0103 PixelRepresentation 0: unsigned. 1: signed. 0028, 1050 WindowCenter DS. 0028, 1051 WindowWidth DS. 0028, 1052 RescaleIntercept DS. 0028, 1053 RescaleSlope DS. 0028, 2110 LossyImageCompression CS. 0028, 2112 LossyImageCompressionRatio DS. 0028, 2114 LossyImageCompressionMethod CS. 7FE0, 0010 PixelData The pixel data.

A dicom image has a raw data of byte size: ROWS * COLUMNS * NUMBER_OF_FRAMES * SAMPLES_PER_PIXEL * (BITS_ALLOCATED/8). see reference.

Here are some good references:

### UID

• The Study Instance UID is normally generated by the Broker. Every Requested Procedure has his own Study Instance UID, look in the IHE Radiology Volume 1 (SWF and Appendix A) documentation. http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev6.0ft_vol1_2005-05-20.pdf
• The Serie Instance UID is generated in the modality and it keep all the images together from that serie. Every image have this own Instance UID. The UID most be a unique identifier over the world.

DICOM UID encoding rules are defined as follows:

Each component of a UID is a number and shall consist of one or more digits. The first digit of each component shall not be zero unless the component is a single digit.
• Each component numeric value shall be encoded using the characters 0-9 of the Basic G0 Set of the International Reference Version of ISO 646:1990 (the DICOM default character repertoire).
• Components shall be separated by the character "." (2EH).
• If ending on an odd byte boundary, except when used for network negotiation (see PS3.8), one trailing NULL (00H), as a padding character, shall follow the last component in order to align the UID on an even byte boundary.
• UIDs, shall not exceed 64 total characters, including the digits of each component, separators between components, and the NULL (00H) padding character if needed.
http://medical.nema.org/dicom/2013/output/chtml/part05/chapter_9.html. Another good reference introducing UID: http://www.dclunie.com/medical-image-faq/html/part2.html#UID.

# PACS

Free online dicom server:

• [email protected]. findscu -P -k 0008,0052=SERIES -k SeriesInstanceUID="" -k Modality="" -aec hehe 213.165.94.158 11112.

# Multi-frame DICOM

A multi-frame DICOM file with DCM_NumberOfFrames set to 150 frames and DCM_FrameTime set to 20 milliseconds. It's expected to see a playback at 50 FPS which is about 3 second in length.


# FAQs

## Pass BodyParts in DICOM worklist

#### Difference between Acquisition Number (0020,0012) and Instance Number (0020,0013)?

Usually we use Instance Number to decide the Instance order in a series. Acquisition Number is just a fallback, at least in eFilm. See Reference.

#### How to keep DICOMs on server

Reference. You may choose whatever you want for these values, but the Series Number should correspond to the specific Series (identified by the Series Instance UID) and should be unique inside the Study (identified by the Study Instance UID) which is containing the series.

Consequently, the Instance Number should correspond to the specific Instance (identified by the SOP Instance UID) and should be unique inside the specific Series (identified by the Series Instance UID).

I hope this makes it clearer.

If your application is working on a Study and generates a Series that should be displayed first, assign the first Series Number to it, e. g. "1". The Image to be displayed first in the Series (e. g. topmost of the Image Stack) should be assigned the first Instance Number, e. g. "1".

Then the next Series may be numbered "2" and has also Instances in there Numbered "1", "2", ... - I hope you get it, please come back to me if you did not.

# Overlays

NEMA.

• An Overlay Plane describes graphics or bit-mapped text that is associated with an Image. It may also describe a Region of Interest in an Image.
• Each Overlay Plane is one bit deep. Sixteen separate Overlay Planes may be associated with an Image.
• Overlay data is stored in Overlay Data (60xx,3000).
• How an Overlay Plane is rendered is undefined; specifically there is no mechanism to specify with what color or intensity an Overlay Plane is to be displayed, except when rendered under the control of a Softcopy Presentation State SOP Instance.
• Overlay Rows, (60xx,0010).
• Overlay Columns, (60xx,0011).
• Overlay Origin, (60xx,0050). Location of first overlay point with respect to pixels in the image, given as row\column. The upper left pixel of the image has the coordinate 1\1.
• Number of Frames in Overlay, (60xx,0015). Required if Overlay data contains multiple frames.
• Image Frame Origin, (60xx,0051). Frame number of Multi-frame Image to which this overlay applies; frames are numbered from 1.

#### Overlay Type

• (60xx,0040).
• Enumerated Values: G - Graphics, R - ROI.
• A Graphics overlay may express reference marks, graphic annotation, or bit mapped text, etc. A Graphics overlay may be used to mark the boundary of a ROI.

# Modalities

## Intro

• IO:
• OCT: Optical Coherence Tomography
• OT: Other

## MR

### Diffusion

NEMA.

Attribute Name Tag Type Attribute Description
MR Diffusion Sequence (0018,9117) 1 Identifies the diffusion parameters of this frame. Only a single Item shall be included in this sequence.
>Diffusion b-value (0018,9087) 1C Diffusion sensitization factor in sec/mm2. This is the actual b-value for original frames and those derived from frames with the same b-value, or the most representative b-value when derived from images with different b-values. Required if Frame Type (0008,9007) Value 1 of this frame is ORIGINAL. May be present otherwise.
>Diffusion Directionality (0018,9075) 1C Specifies whether diffusion conditions for the frame are directional, or isotropic with respect to direction.
Defined Terms:
DIRECTIONAL
BMATRIX
ISOTROPIC
NONE
To be used when Frame Type (0008,9007) value 4 equals DIFFUSION_ANISO or Diffusion b-value (0018,9087) is 0 (zero).
Required if Frame Type (0008,9007) Value 1 of this frame is ORIGINAL. May be present otherwise.
>Diffusion Gradient Direction Sequence (0018,9076) 1C Sequence containing orientations of all diffusion sensitization gradients that were applied during the acquisition of this frame. Only a single Item shall be included in this sequence. Required if Diffusion Directionality (0018,9075) equals DIRECTIONAL May be present if Diffusion Directionality (0018,9075) equals BMATRIX.
>>Diffusion Gradient Orientation (0018,9089) 1C The direction cosines of the diffusion gradient vector with respect to the patient Required if Frame Type (0008,9007) Value 1 of this frame is ORIGINAL. May be present otherwise.
>Diffusion b-matrix Sequence (0018,9601) 1C The directional diffusion sensitization expressed as a 3x3 matrix with diagonal symmetry (with six unique elements from which the other elements can be derived). The rows and columns of the matrix are the X (right to left), Y (anterior to posterior) and Z (foot to head) patient-relative orthogonal axes as defined in Section C.7.6.2.1.1. The values are in units of ms/mm2. Only a single Item shall be included in this sequence. Required if Diffusion Directionality (0018,9075) equals BMATRIX.
>>Diffusion b-value XX (0018,9602) 1 The value of b[X,X].
>>Diffusion b-value XY (0018,9603) 1 The value of b[X,Y].
>>Diffusion b-value XZ (0018,9604) 1 The value of b[X,Z].
>>Diffusion b-value YY (0018,9605) 1 The value of b[Y,Y].
>>Diffusion b-value YZ (0018,9606) 1 The value of b[Y,Z].
>>Diffusion b-value ZZ (0018,9607) 1 The value of b[Z,Z].
>Diffusion Anisotropy Type (0018,9147) 1C Class of diffusion anisotropy calculation.
FRACTIONAL
RELATIVE
VOLUME_RATIO
Required if Frame Type (0008,9007) value 4 equals DIFFUSION_ANISO.

## SR

• Structured Reporting (SR).
• The contents of the leaves are defined, for example they contain findings, measurements, codes, names, date/times, and, probably the most important, references to other DICOM objects.
• SR could be used in:
• Computer Aided Detection (CAD) output from a computer.
• There are niches that today provide reports for a specific applications, such as Endoscopy, Ophthalmology, OB/GYN, etc. SR is a logical evolution to deal with images as well as text.
• Cardiology generates procedure logs in a very structured format. These lend themselves very well to the SR application. Templates are being defined.
• Ultrasound definitely needs a standard for their measurements. Many proprietary solutions exist that are in the process of being converted to SR.
• The key image note to identify key images in a study might actually become the biggest driver of SR implementations, especially because image acquisition modalities are increasingly producing more and more images. The SR mechanism to provide image references with additional text providing the mage context ("significant images") would allow identifying the selected images for a physician, not requiring downloading all of them.

# Dicom Communications

### Roles in C-Get

This discussion in DCMTK forum said:

The default role means that the association requestor is the SCU and the association acceptor is the SCP. For a successful C-Get operation, the c-store operations must reverse the roles. So, your getscu should propose SCP role for MR image storage. If you are using the last snapshot, you will find the function addPresentationContext() in DCMSCU class that takes the role of the SOP class as a parameter.

You can find explanation for role selection negotiation in PS 3.7 D.3.3.4. For C-Get operation look at PS 3.4.

Therefore, in DCMTK, we have  

for (Uint16 i = 0; i < numberOfDcmLongSCUStorageSOPClassUIDs; i++) {
ts, ASC_SC_ROLE_SCP); // Not ASC_SC_ROLE_SCU!
}

 

# Query and Retrieve

There are three Query/Retrieve Information Models:

• Patient root
• Study root
• Patient/Study only

There are four levels:

• Patient
• Study
• Series
• Composite object instance
For example, the patient level is the top level and contains Attributes associated with the Patient Information Entity (IE) of the Composite IODs as defined in PS 3.3. Patients IEs are modality independent.

The Study Root Query/Retrieve Information Model is identical to the Patient Root Query/Retrieve Information Model except the top level is the study level. Attributes of patients are considered to be Attributes of studies.

The previous is referenced from http://www.dabsoft.ch/dicom/4/C.3/.

#### Web service

Ref.

 

// Query request.
<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
<QueryRoot>STUDY</QueryRoot>
<QueryLevel>STUDY</QueryLevel>
<Match>
<Attribute Tag="00100010">FEROVIX</Attribute>
<Attribute Tag="00080050">1210490</Attribute>
</Match>
<Return>
<Attribute Tag="00080054"/>
</Return>
</DICOM:FindMove>

// a DICOM C-FIND results message with the SOAP response envelope removed:
<DICOM:Results xmlns:DICOM="http://com.ibm.healthcare/DICOM">
<DICOM>
<Attribute Tag="00080005" VR="CS">ISO_IR 100</Attribute>
<Attribute Tag="00080016" VR="UI">1.2.840.10008.5.1.4.1.1.2</Attribute>
<Attribute Tag="00080018" VR="UI">1.3.12.2.1107.5.1.4.54023.30000004093016410718700003864</Attribute>
<Attribute Tag="00080052" VR="CS">IMAGE</Attribute>
<Attribute Tag="00080054" VR="AE">PACS</Attribute>
<Attribute Tag="00080056" VR="CS">ONLINE</Attribute>
<Attribute Tag="0020000D" VR="UI">1.3.12.2.1107.5.1.4.54023.30000004093013443132800000021</Attribute>
<Attribute Tag="0020000E" VR="UI">1.3.12.2.1107.5.1.4.54023.30000004093016410718700003676</Attribute>
<Attribute Tag="00200013" VR="IS">188</Attribute>
<Attribute Tag="00880130" VR="SH"/>
<Attribute Tag="00880140" VR="UI"/>
</DICOM>
</DICOM:Results>

// C-MOVE request messages are set up exactly the same as C-FIND request messages. The only difference is the inclusion of a MoveDestination element in the XML query message.
// C-MOVE request:
<DICOM:FindMove xmlns:DICOM="http://com.ibm.healthcare/DICOM">
<QueryRoot>PATIENT</QueryRoot>
<QueryLevel>STUDY</QueryLevel>
<MoveDestination>REMOTEAE</MoveDestination>
<OperationPriority>NORMAL</OperationPriority>
<Match>
<Attribute Tag="PatientID">fWT0KTL</Attribute>
<Attribute Tag="AccessionNumber">1210490</Attribute>
</Match>
<Return>
</Return>
</DICOM:FindMove>

 

A Composite IOD is an Information Object Definition which represents parts of several entities included in the DICOM Model of the Real-World. Such an IOD includes Attributes which are not inherent in the Real-World Object that the IOD represents but rather are inherent in related Real-World Objects.

The following conventions are used to define the types of keys used in Query/Retrieve Information Models.

Symbol		Description
U		Unique Key Attribute
R		Required Key Attribute
O		Optional Key Attribute


 

# 0008,0052=SERIES must be capitalized!
# Since specifying SeriesIUID, so the Q/R level 0008,0052 is series but not study or patient.
# I encountered "Identifier does not match SOP Class", and found out it was beause of the previous two reasons.
# You have to configure at your DCM4CHEE to add the ae: movescu yourIP 5004.
movescu -d -P -k 0008,0052=SERIES -k PatientID=patID -k StudyInstanceUID=StudyIUID -k SeriesInstanceUID=SeriesIUID -aec DCM4CHEE -aem movescu --port pacsPort pacsIP 11112

  Note: DCMTK findscu accepts four strings for 0008,0052: PATIENT, STUDY, SERIES, IMAGE.

Reference: C-MOVE Service Parameters.

### How to get the number of instances?

https://www.medicalconnections.co.uk/kb/Counting_Studies_Series_and_Instances is a good reference.

Note that:

• The following is strongly recommended but not enforced in DICOM, so your PACS may not even support them!
• All the attributes are only valid in C-FIND queries, and are not valid within instances.
Attribute Name Tag Attribute Description
Number of Patient Related Studies (0020,1200) The number of studies that match the Patient level Query/Retrieve search criteria
Number of Patient Related Series (0020,1202) The number of series that match the Patient level Query/Retrieve search criteria
Number of Patient Related Instances (0020,1204) The number of composite object instances that match the Patient level Query/Retrieve search criteria
Number of Study Related Series (0020,1206) The number of series that match the Study level Query/Retrieve search criteria
Number of Study Related Instances (0020,1208) The number of composite object instances that match the Study level Query/Retrieve search criteria
Number of Series Related Instances (0020,1209) The number of composite object instances in a Series that match the Series level Query/Retrieve search criteria
SOP Classes in Study (0008,0062) The SOP Classes contained in the Study.

The following shows how to use findscu to do queries.  

# STUDY: Find studyDate, studyTime, studyIUID.

findscu -P -k PatientID=7100297871 -k 0008,0052=STUDY -k StudyInstanceUID="" -k StudyDate="" -k StudyTime="" -aec DCM4CHEE 192.168.10.204 11112 2>&1 | tr -d '[]()\000' | grep -e "StudyInstanceUID\|StudyDate\|StudyTime" | cut -d ' ' -f4

# SERIES: Modality, SeriesIUID, NumberOfSeriesRelatedInstances.

findscu -S -k 0008,0052=SERIES -k StudyInstanceUID="1.2.840.113704.1.111.976.1398840889.1" -k SeriesInstanceUID="" -k 0020,1209="" -k Modality="" -aec DCM4CHEE 192.168.10.204 11112 2>&1 | tr -d '[]()\000' | grep -e "SeriesInstanceUID\|Modality\|NumberOfSeriesRelatedInstances" | cut -d' ' -f4

 

### Retrieving the "Modality" in a C-FIND

Ref.

• Since a DICOM study is allowed to contain multiple series, each with perhaps different modalities, the only valid place for the 0008,0060 (Modality) attribute is in a SERIES level query.
• The solution (where supported) is to use the alternative STUDY Level Attribute 0008,0061 (ModalitiesInStudy, CS, Multiplicity 1-n) which returns a list of Modality values used in the study. It is optional, but most server will support it, see below.
• "Support of Modalities in Study as matching key is required by the IHE Radiology Scheduled Workflow Profile for Image Managers/Image Archives, archives which does not support them are not IHE compliant!"Ref.
• DICOM (in general) does not allow multiple value matching for anything except UIDs, so it is not valid for a query to contain multiple values in the 0008,0061 field.

### Find related DCM tags

Go to dicomtags website, type search keywords in "Search by Description: Tag Description" box. For example, if you want to search Modality-related tags, type "modalit". Don't use the full spelled "modality", since you may miss the plural form "modalities", for example "ModalitiesInStudy".

### How to check whether PACS support c-get?

• Check the DICOM conformance statement of the PACS.
• With dcmtk commandline tools, turn on -d for debug info.
With getscu -d, info like the following shows c-get is not supported:
D: Presentation Contexts:
D:   Context ID:        1 (Abstract Syntax Not Supported)
D:     Abstract Syntax: =GETPatientRootQueryRetrieveInformationModel
D:     Proposed SCP/SCU Role: Default
D:     Accepted SCP/SCU Role: Default


Reference: http://forum.dcmtk.org/viewtopic.php?t=3153.

#### ITK mhd says RAI for FFS images?

I was severely confused by this, before I re-read the following paragraphs from this kitware page:

The InsightSNAP tool in InsightApplications (which has a great IO loader by the way), uses the following: When it says LPS it means the x axis is RUNNING FROM left to right, the y axis is running from Posterior to Anterior, the z axis is running from Superior to Inferior.
This is exactly the same as what DICOM means when it says RAI.

Now it is clear now: When DICOM says LPS, it means the direction the axises point to; while MHD syas RAI in AnatomicalOrientation, it means the direction the axises run from. In short, the MHD AnatomicalOrientation is always flipped in all dimensions when compared to DICOM patientPosition. Nevertheless, the TransformMatrix in MHD is conformant.

# weasis

Weasis is a multipurpose web-based DICOM viewer with a highly modular architecture. Weasis can be easily connect to any PACS supporting WADO via a web portal or as an XDS-I consumer in an IHE (Integrating the Healthcare Enterprise) environment. Reference.