By Jeff Kabachinski
This issue of Tech Savvy explores the DICOM association process. DICOM is the universal communication standard that imaging devices use in a PACS (Picture Archive Computer System). It allows cross-vendor communication of things like diagnostic images, ECG waveforms, diagnostic reports and workflows. However, none of this can happen without two Application Entities (AEs what DICOM calls DICOM compliant devices or network nodes) first recognizing a connection.
An association process sets in place all the details required to ensure proper connection and interoperability between devices from varying vendors. Since DICOM intends to be as diverse as possible to enable connection with “anyone“ the standard can be complex in all the various types of encoding. In other words, because DICOM attempts to include all connection nuances from all manufacturers the standard becomes large and complex but accommodating. This is why the DICOM association is detailed but vitally important.
The association process has a number of informative precepts to be sure and identify during the association including:
- Abstract syntax
- Transfer syntax
- Protocol data units (PDUs)
- Application context
- Presentation context
- User Information
Abstract Syntax
The abstract syntax identifies the nonnegotiable portion of the impending association and data transfer. It stipulates aspects that cannot be changed. For example, if you’re an MR scanner you’ll be limited to dealing with MR images – not CT, XR or any other modality. The abstract syntax also identifies whether you’re a SCU (Service Class User – like a network client) or a SCP (Service Class Provider – like a network server). Unless I’m a SCP I won’t be able to send or provide anything.
Transfer Syntax
Next is the transfer syntax to identify how the data transfer will be encoded – little endian or big endian for example. In hexadecimal byte ordering the most significant byte is left most or comes first in big endian. Little endian is the reverse. For example, A1 in big endian has a decimal value of 161 and a value of 26 in little endian so we better know the format of the data coming across. The transfer syntax also establishes which of the seven data compression formats the AE has in their toolbox.
PDUs
The PDUs in DICOM refer to the commands themselves including:
- A-Associate-RQ PDU – requests DICOM association
- A-Associate-AC PDU – accepts DICOM association
- A-Associate-RJ PDU – rejects DICOM association
- P-DATA TF PDU – transfers DICOM data
- A-Release-RQ PDU – requests to terminate the association
- A-Release-RP PDU – OK let’s terminate the association
- A-Abort PDU – aborts an invalid association
Application context
The Application context does not add to the negotiated communication parameters. It defines the context of the application in the requesting AE. For example, if I’m running GE software and the requested AE is also a GE device with the same software, I’d immediately know that I could use some proprietary data transfer scheme.
Presentation Context
The presentation context refers to the pairing of the abstract syntax and transfer syntax that can be used. The abstract syntax is the subject of the discussion and the transfer syntax is the language to be used. An SCP may be able to use several types of data compression, for example, and the SCU chooses which one it prefers from the list.
User Information
The user in the user information field refers to the requesting AE. This is a list of details important to the data transfer. Called sub-items these are things like specifying the maximum size of a data block that I can handle.
Summary
The idea here was to present a brief overview and demystify the things that occur during a DICOM association while introducing some DICOM-ese. All the grim details can be found in the DICOM standard at dicom.nema.org. The standard has 20 parts as shown in the sidebar. PS3.7 is where you can find the list of user information sub-items, for example. If you have insomnia, reading the DICOM parts could be a good solution for you!