DICOM Error and Warning Codes
Below is a list of common DICOM Error/Warning Codes (not necessarily a complete list):
Code (Hex) Code (Decimal) Warning Failure Meaning 105 261 Y No such attribute 106 262 Y Invalid attribute value 107 263 Y Attribute List Error 110 272 Y Processing failure 111 273 Y Duplicate SOP instance 112 274 Y No such object instance 113 275 Y No such event type 114 276 Y No such argument 115 277 Y Invalid argument value 116 278 Y Attribute Value Out of Range 117 279 Y Invalid object instance 118 280 Y No such SOP class 119 281 Y Class-instance conflict 120 282 Y Missing attribute 121 283 Y Missing attribute value 122 284 Y SOP class not supported 123 285 Y No such action type 210 528 Y Duplicate invocation 211 529 Y Unrecognized operation 212 530 Y Mistyped argument 213 531 Y Resource limitation
Every DICOM Association starts with a process of negotiation whereby the Application Entities involved exchange sufficient information about themselves to allow proper communication. The information passed in the initial request includes:
The AETs of the two applications The list of Presentation Contexts request, each containing a list of Transfer Syntaxes Any Reverse Role Negotiation requests Any Extended Negotiation requests Miscellaneous “User Information” including
The name and UID of the software The maximum data packet size that may be received The acceptance packet contains mostly the same information but each Presentation Context is either accepted or rejected, and if accepted, only a single Transfer Syntax” per Presentation Context is specified.
A Presentation Context may be considered as a negotiated “sub-channel” with a DICOM Association through which the Application Entities have agreed to exchange information.
A proposed presentation context consists of
A presentation context ID (an odd integer <= 255, and unique within the association) A SOP Class or Meta SOP Class A list of proposed Transfer Syntaxes This is considered by the requesting Application Entity which either rejects it completely or accepts, in which case the list of proposed transfer syntaxes is replaced by a single accepted transfer syntax which is then used for all communications using that presentation context.
Service Class Roles
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.
Significance of AssociationClosed Event
The AssociationClosed Event is provided in both COM & .NET versions, but by default disabled.
Some Systems Behave Badly when sent One Image Per Association
Unfortunately, the designers of some systems seem never to have bothered to read the DICOM standard.
The only legal way to group images into series and studies is by using their UIDs, but there is a problem as DICOM has no simple “end of study” marker, and therefore many badly-designed (but common!) systems make the mistake of assuming that the end of an association equals the end of a study.
Transfer Syntax is the language used in DICOM to describe the DICOM file format and the network transfer methods. 3 main variables are contained in the Transfer Syntax:
VR: Implicit/Explicit Endianism: Little-Endian/BigEndian Pixel Data Compression For DICOM Files, the Transfer Syntax is stored in the File Meta Header, and for networking it is negotiated between the SCU & SCP. For more information about how the negotiation happens and how to control the network transfer using Transfer Syntax can be found here.