DICOM—Digital Imaging and Communications in Medicine—is the international standard for medical images and related information. It defines more than a file format. It describes information objects, data elements, network services, media storage, display behavior, security-related mechanisms, and conformance expectations that allow imaging systems to exchange meaningful data.
Key takeaways
- A DICOM object combines pixel or other content with structured attributes.
- Devices use defined services over an association, with roles negotiated for each service.
- Successful network contact does not prove that a complete clinical workflow is configured correctly.
01
Objects and attributes
A DICOM data set contains attributes identified by tags. Attributes can describe the patient, order, study, series, equipment, acquisition, geometry, and image, as well as the pixel data itself. The required and conditional attributes depend on the information object definition and the real-world entity being represented.
DICOM also covers non-image objects, including structured reports, waveforms, presentation states, radiation-dose objects, and encapsulated documents. Thinking of DICOM only as a .dcm image file misses most of the interoperability model.
02
Services and associations
Two applications establish an association and negotiate application entities, presentation contexts, transfer syntaxes, and roles. A storage service can send an object; query/retrieve services can search and move data; modality worklist can provide scheduled procedure information; verification can test a basic DICOM echo. Each service has defined request and response behavior.
03
Conformance matters
A DICOM conformance statement describes which objects, services, roles, transfer syntaxes, attributes, and options a product supports. Two products can both claim DICOM support but implement different service classes or optional behavior. Integration planning should compare the relevant conformance statements and the intended workflow.
04
A practical troubleshooting model
Separate transport, association, service, object, and workflow layers. Can the devices reach each other on the network? Does the association negotiate? Is the requested service supported? Is the object valid and accepted? Does it contain the identifiers the receiving workflow expects? This layered model is more useful than treating every failure as a generic DICOM problem.
Related terminology
Terms with a published definition link directly to the glossary.
Authoritative starting points
These external sources support additional study; always use the version applicable to your equipment and jurisdiction.
DICOM Standard: Overview ↗Current DICOM Standard ↗