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 (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:
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 126.96.36.199 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 188.8.131.52.
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.
DCMTK Doc on asconfig.
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.
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:
PresentationContext1 = UltrasoundImageStorage\Uncompressed
PresentationContext2 = UltrasoundMultiframeImageStorage\Uncompressed
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.
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.
- 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.
- 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.
- 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.
- 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.
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.
- 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-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.
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 (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.
- 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 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.
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).
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.
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.
- 1.2.840.10008.5.1.4.1.1.7 Secondary Capture Image Storage
Dicom tag values
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”
The groups are organized as follows:
|0028 ||Image Presentation|
|6000-601E (even) ||Overlay|
|7FE0 ||Pixel Data|
||VR (value representation)
||CS (code string, 16 bytes maximum.). Example: study
||PN (person name, 64 bytes maximum.).
||LO (long string, 64 bytes maximum.).
||UI (unique identifier, 64 bytes max).
||UI (unique identifier, 64 bytes max).
||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.
||US (unsigned short).
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.
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.
||US (unsigned short).
||US (unsigned short).
||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.
||0: unsigned. 1: signed.
||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:
- 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.
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.
- 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.
Query and Retrieve
There are three Query/Retrieve Information Models:
- Patient root
- Study root
- Patient/Study only
There are four levels:
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.
- Composite object instance
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/.
// Query request.
// a DICOM C-FIND results message with the SOAP response envelope removed:
<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">184.108.40.206.1220.127.116.11.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">18.104.22.168.122.214.171.124.54023.30000004093013443132800000021</Attribute>
<Attribute Tag="0020000E" VR="UI">126.96.36.199.1188.8.131.52.54023.30000004093016410718700003676</Attribute>
<Attribute Tag="00200013" VR="IS">188</Attribute>
<Attribute Tag="00880130" VR="SH"/>
<Attribute Tag="00880140" VR="UI"/>
// 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:
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.
U Unique Key Attribute
R Required Key Attribute
O Optional Key Attribute
Note: DCMTK findscu accepts four strings for 0008,0052: PATIENT, STUDY, SERIES, IMAGE.
# 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
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.
- 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
|| Attribute Description
| Number of Patient Related Studies
|| The number of studies that match the Patient level Query/Retrieve search criteria
| Number of Patient Related Series
|| The number of series that match the Patient level Query/Retrieve search criteria
| Number of Patient Related Instances
|| The number of composite object instances that match the Patient level Query/Retrieve search criteria
| Number of Study Related Series
|| The number of series that match the Study level Query/Retrieve search criteria
| Number of Study Related Instances
|| The number of composite object instances that match the Study level Query/Retrieve search criteria
| Number of Series Related Instances
|| The number of composite object instances in a Series that match the Series level Query/Retrieve search criteria
| SOP Classes in Study
|| 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
- 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?
With getscu -d, info like the following shows c-get is not supported:
- Check the DICOM conformance statement of the PACS.
- With dcmtk commandline tools, turn on -d for debug info.
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