What is DICOM, and what does the standard actually do?

DICOM is the common standard that lets imaging equipment and clinical systems exchange images with structured information about the study. It defines data objects and network services, but it does not by itself select a reader, create a report, establish authorization, encrypt every connection, or make a workflow compliant.

A radiology study is more than a stack of pictures. Its DICOM objects may carry the modality, study and series identifiers, acquisition details, image orientation, timestamps, and other attributes that receiving systems use to organize the examination. Those attributes help a PACS or another authorized system keep the right series together and present them in a useful order. They must also be handled as sensitive health information whenever they identify a patient or connect to an identifiable record.

How does a study move from a facility to a remote reader?

A typical route begins at the modality or facility archive, sends the authorized study to a configured DICOM receiving node, and makes it available to the intended reading workflow. Routing rules may then place the study on a worklist based on agreed attributes, while the facility retains responsibility for acquisition and patient care.

At acquisition, a technologist completes the examination under the facility's approved process. Images may first enter the local PACS, or a modality may send a copy toward another authorized destination. The sender and receiver are configured with network addresses, ports, and application entity titles. Those technical identifiers are necessary for traditional DICOM networking, but access should also be limited by approved routes, authenticated systems, and the security design around the connection.

What roles do the PACS, router, worklist, and report system play?

The PACS stores and retrieves imaging objects; a router directs authorized traffic; a worklist organizes studies for eligible readers; and a reporting system captures and returns the interpretation. One product may perform several roles, but each handoff still needs an owner, acceptance criteria, monitoring, and a documented downtime path.

PACS is often used as shorthand for the whole imaging environment, but separating the functions makes an integration easier to test. Storage answers whether every expected object arrived and remains retrievable. Routing answers where an authorized copy goes and under which rules. Worklist logic answers who can see a study and how its status changes. Reporting answers where the signed interpretation is stored and how it reaches the facility's clinical record or other approved destination.

  • Confirm which system is the authoritative source for the order, patient identity, study status, and final report.
  • Define how duplicates, corrected demographics, canceled studies, late series, and unavailable priors are handled.
  • Document who monitors each handoff and who can safely retry, reroute, or reconcile an exception.
  • Keep a usable downtime and recovery process outside the ordinary automated path.

How should a DICOM route be validated before cutover?

Validation should begin with controlled, non-PHI test studies and follow them from the sending system through routing, storage, worklist display, interpretation, report return, and reconciliation. A responsible target architecture calls for end-to-end non-PHI testing before cutover, and a route that passes one send test can still fail on the second modality or on a corrected demographic.

A protocol check is only the first layer. The team should verify network reachability, expected calling and called application entity titles, supported transfer syntaxes, complete series counts, image order, compression behavior, and character display. It should then confirm that the work item reaches only the intended queue, with the expected priority and context, and that the reader can open the entire study without relying on a hidden manual workaround.

  • Use synthetic or otherwise approved non-PHI objects that cannot be mistaken for a real patient study.
  • Test every modality, transfer pattern, worklist destination, report destination, and relevant character set in scope.
  • Record expected results, observed results, exception ownership, and the decision required before go-live.
  • Repeat validation after material routing, interface, security, or endpoint changes.

When does interpretation begin, and how does the report return?

Interpretation can begin only after an eligible reader has a complete, accessible study and the context required by the agreed workflow. The signed report then returns through the facility's approved interface or repository. Image arrival, worklist assignment, report signature, delivery, acknowledgment, and critical communication are distinct events that should not be collapsed.

A transfer timestamp may show when a receiving service accepted an object, but it does not prove that all series arrived or that the study was ready to read. A worklist timestamp may show assignment, not that the radiologist opened the case. A report signature may show completion of interpretation, while interface delivery and posting to the clinical record occur later. Facility service definitions should specify which event starts and stops any measured interval.

Which security controls belong in a responsible architecture?

A responsible architecture should address encryption in transit, encryption at rest, role-based access, authentication, audit logging, retention, incident response, and executed business associate agreements where required. A facility should require documentary evidence of each of those controls from any teleradiology vendor before clinical cutover, because support for a standard is not the same thing as an operating control.

TLS can protect data while systems exchange it, but only when the relevant connection is configured to use it and certificates, protocols, and endpoints are managed correctly. A DICOM implementation that can support secure transport may also allow an unencrypted route. The team must inspect the actual production configuration, including any tunnel, private network, gateway, DICOMweb service, or intermediary, rather than treating support as proof of use.

Who is responsible for each DICOM workflow decision?

Responsibility is shared but should never be vague: the facility owns acquisition and local patient care; technical teams own approved connectivity and interfaces; the reading organization owns its authorized environment and professional workflow; and designated clinical leaders own communication policies. Contracts and procedures must allocate duties, exceptions, and escalation explicitly.

The facility determines which studies are authorized to leave its systems, supplies accurate order and demographic information, completes acquisition under its policies, and manages local patient-facing care. It also controls its source systems, approved destinations, and local access. A remote reading organization should not correct identifiers, infer a missing order, or accept an incomplete study outside an agreed reconciliation process.

What should a facility ask before approving a DICOM connection?

A facility should ask for an exact data-flow diagram, supported standards, security configuration, worklist and report behavior, test plan, exception ownership, downtime procedure, change control, and evidence for every claimed safeguard. It should also separate a reference architecture from controls documented and validated in the production environment.

Begin with scope: modalities, locations, expected study patterns, urgency categories, hours, priors, report destinations, and required jurisdictions. Ask which components receive, store, route, display, or transform protected information and which organization operates each component. Confirm whether any subcontractor participates and where authorized data are processed. These answers determine what must be secured and which agreements and reviews apply.

  • Which statements describe a future target, and which controls have been observed or documented in production?
  • How are encryption, access, auditing, retention, incident response, and agreements verified and maintained?
  • What are the acceptance criteria for image completeness, worklist visibility, report return, and exception recovery?
  • Who has authority to pause, roll back, or restore the route when a test or production event fails?

Sources and scope

  • DICOM Standard, National Electrical Manufacturers Association
  • HIPAA Security Rule guidance, U.S. Department of Health and Human Services
  • Integrating the Healthcare Enterprise Radiology Technical Framework
  • DLA Imaging editorial policy