What Is a DICOM AE Title? Meaning, Format, and Examples

01

AE Title meaning in plain language

DICOM systems communicate as application entities. An application entity can be a modality storage sender, PACS receiver, modality-worklist provider, query/retrieve service, print service, or another DICOM-capable application. The AE Title is the configured name used to identify that application during a DICOM association.

One physical computer can host several DICOM applications with different AE Titles or ports. Conversely, one modality can use separate local AE Titles for storage, worklist, query/retrieve, or specialized workflows. This is why copying the computer name into every AE Title field is not a reliable integration method.

02

AE Title format and naming

The DICOM AE value representation has a maximum length of 16 bytes in the standard character repertoire. Equipment interfaces may apply additional rules, such as restricting spaces or automatically changing case. Preserve the configured value exactly when documenting or comparing endpoints, and check the product's DICOM conformance statement and integration instructions for implementation-specific behavior.

A practical local naming convention often reflects function or location, but the name itself does not create routing. An AE Title such as XR_ROOM_1 does not tell the network where that application is located; the destination entry still needs the correct address, port, supported service, and security configuration.

• Maximum DICOM AE value length: 16 bytes.
• Use a deliberate, documented name rather than assuming the computer name is required.
• Avoid visually ambiguous names, accidental spaces, duplicate entries, and undocumented reuse.
• Treat case handling as implementation-specific even when a system appears tolerant.

03

AE Title versus IP address and port

A destination record commonly combines three different identifiers. The called AE Title names the DICOM application being requested. The IP address or DNS name locates a network interface. The TCP port identifies the listening service on that address. All three must describe the intended endpoint, but changing one does not automatically update the others.

Network address translation, multiple network interfaces, clustered services, application gateways, TLS proxies, or redundant servers can make the relationship less obvious. Document the logical DICOM application separately from the underlying network path so infrastructure changes do not erase the intended workflow.

• AE Title: Which DICOM application?
• IP address or hostname: Which network destination?
• TCP port: Which listening service at that destination?
• Supported DICOM service: What operation is being requested?

04

Calling and called AE Titles

The calling AE Title identifies the application initiating the association. The called AE Title identifies the application it wants to reach. When a modality sends images to PACS, the modality commonly presents its local AE Title as the calling AE and names the PACS storage AE as the called AE. For modality worklist, query/retrieve, or other services, the initiating role and direction may differ.

A receiving application can be configured to accept only expected calling AE Titles, addresses, services, or security conditions. An association can therefore be rejected even when basic network connectivity succeeds. Authorization rules, routing rules, service capability, and conformance negotiation are separate layers.

05

A fictional DICOM endpoint example

Consider a fictional X-ray modality with AE Title XR_ROOM_1 at documentation-only address 192.0.2.10. Its PACS destination is configured with called AE Title PACS_STORE at documentation-only address 198.51.100.20 and TCP port 104. When the modality initiates storage, XR_ROOM_1 is the calling AE and PACS_STORE is the called AE.

Those values are examples, not recommended production settings. A working configuration also depends on supported storage services, transfer syntaxes, network policy, TLS requirements where used, receiving-system authorization, patient and order identifiers, and the facility's approved integration design.

• Calling AE: XR_ROOM_1
• Called AE: PACS_STORE
• Destination address: 198.51.100.20
• Destination port: 104
• Intended function: supported DICOM storage service

06

Common AE Title configuration mistakes

Common errors include swapping calling and called values, entering a hostname where an AE Title is expected, using the correct AE Title with the wrong port, pointing to a service that is not listening, omitting the sender from an authorization list, duplicating a destination, or testing through a different network interface than the production application uses.

Case differences, trailing spaces, hidden characters copied from documents, old destination records, NAT, firewall rules, TLS mismatch, clock or certificate problems, and software changes can complicate the symptom. Diagnose the layer that failed rather than changing several fields at once.

• Confirm the intended DICOM service and direction.
• Compare calling AE, called AE, address, and port as separate fields.
• Check that the receiving application recognizes the sender and supports the requested service.
• Use test patients and approved diagnostic tools; never expose clinical endpoint details publicly.

07

What DICOM Echo proves—and what it does not

DICOM Verification, commonly called DICOM Echo, can show that two applications reached the verification service and successfully negotiated that limited operation. It is useful evidence, but it does not prove that storage, modality worklist, query/retrieve, storage commitment, printing, or another service is configured and supported.

Echo also does not prove that patient identifiers, accession numbers, procedure data, routing, archive indexing, display behavior, or downstream clinical workflow are correct. Separate network reachability, association negotiation, service capability, object acceptance, and workflow behavior when documenting a problem.

08

Document the endpoint

Record the logical function, local or remote role, AE Title exactly as configured, IP address or DNS name, port, supported service, TLS or certificate requirements, network zone, owner, related interface, conformance statement, change history, and an approved test result. Clear endpoint records reduce accidental reuse and make later infrastructure changes easier to evaluate.

Do not publish real clinical endpoint details, patient data, credentials, private addresses, certificates, or screenshots from protected systems in public support requests. Use manufacturer procedures, facility change controls, and authorized integration testing for production systems.