What is a DICOM Application Entity (AE) title?

In DICOM networking, an Application Entity title (AE title) is a unique string of up to 16 characters that names a specific DICOM program or service. When two medical systems communicate—like a CT scanner sending images to an archive—they identify each other by their AE titles during association negotiation.

Think of an AE title like a DNS hostname or a named service endpoint, but at the DICOM application layer. It identifies software services rather than physical computers. A single workstation or server running multiple imaging applications can host multiple distinct AE titles on the same network interface.

How AE titles work on a DICOM network

DICOM devices communicate using stateful, negotiated network sessions called associations. Every association begins with an exchange of identifiers:

• Calling AE title: The identifier of the client initiating the association request.
• Called AE title: The identifier of the destination service that accepts the request.

Consider a hospital CT scanner sending images to an archive. The scanner presents CT_SCAN_01 as the Calling AE title. It requests PACS_ARCHIVE as the Called AE title.

The receiver checks the requested Called AE title against its active services. If the title does not match, or if the receiver does not recognize CT_SCAN_01, it rejects the association immediately.

This exchange happens during association negotiation, before any DICOM dataset moves across the wire. During this step, the systems also agree on supported data types and compression formats. To see how these rules are established, read our guide on DICOM SOP Classes and Transfer Syntaxes explained. Once both sides accept the association, the systems exchange DICOM Message Service Element (DIMSE) operations, such as C-STORE for image transfers or C-ECHO for connectivity verification. For an overview of how verification works and how to troubleshoot failed connections, read our guide on DICOM C-ECHO verification and connectivity testing.

The 16-character rule and formatting constraints

The DICOM standard defines strict constraints for AE titles in Part 5 (PS3.5, Value Representation “AE”):

• Maximum length: 16 bytes (characters).
• Allowed characters: Standard ASCII alphanumeric characters, underscores, and hyphens.
• Forbidden characters: Control characters, backslashes (\), line feeds, and carriage returns.
• Spaces: Leading and trailing spaces are not significant and are ignored or stripped by conformant parsers. An AE title cannot consist entirely of spaces.
• Case sensitivity: The standard treats AE titles as case-sensitive. In practice, MY_PACS and my_pacs are distinct titles, though some software flattens titles to uppercase.

Because of the 16-character limit, organizations use abbreviated naming patterns. A typical hospital convention combines modality type, room number, or site name:

RAD_CT_ROOM2     (12 characters)
PACS_RECEIVE     (12 characters)
MR_BAY_3         (8 characters)
CLINIC_ARCHIVE   (14 characters)

Exceeding 16 characters causes connection failures. Some legacy modalities truncate strings silently after byte 16. This produces hard-to-diagnose mismatches with the receiving system.

Why AE titles provide identity without security

The most important architectural fact about AE titles is that they provide unauthenticated identity. An AE title is a self-declared string transmitted in cleartext inside the association request. Nothing in the core DICOM protocol cryptographically verifies that a sender actually owns the AE title it presents.

In a traditional hospital local-area network (LAN), this lack of authentication was accepted because physical firewalls and network segmentation separated radiology networks from external traffic. On a closed subnet, an AE title acted as a convenient routing label and basic filter. Administrators configured an allowlist of permitted Calling AE titles to prevent unintended devices from flooding an archive.

However, treating an AE title as a security credential creates severe vulnerabilities:

1. Spoofing: Any device on the network can open a connection using any Calling AE title it chooses.
2. Cleartext exposure: Standard DICOM associations transmit AE titles, commands, and imaging datasets unencrypted on port 104 or port 11112.
3. No access delegation: AE titles cannot represent fine-grained permissions, expiration dates, or cryptographic revocation.

If you connect imaging equipment across the public internet, an AE title alone cannot protect patient data. To securely identify senders over public routes, modern systems layer mutual TLS (mTLS) underneath DICOM. In an mTLS connection, cryptographic client certificates establish verified identity before any DICOM association negotiation begins. For details on securing imaging traffic across networks, read our guide on mutual TLS for DICOM connections.

Common configuration failures in production

When integration engineers troubleshoot failed DICOM connections, AE title mismatches cause most initial errors. Here are the three most frequent failure modes:

1. Case mismatch and hidden whitespace

The DICOM standard specifies case sensitivity. A mismatch between PACS_STORE and Pacs_Store causes the receiving system to reject the association. The error often reads “Called AE title not recognized”.

Hidden whitespace creates similar issues. Copying an AE title with an accidental trailing space into a web console causes silent rejection if the software treats the string literally.

2. Reciprocal configuration asymmetry

DICOM storage requires reciprocal setup on both nodes. System A must know System B’s IP address, port, and Called AE title. System B must also know System A’s Calling AE title.

If a hospital administrator adds a new modality to the scanner but forgets to add the Calling AE title to the PACS allowlist, transfers fail immediately.

3. Modality character limits

Some older medical imaging devices enforce limits shorter than 16 characters, like 8 or 10 characters. If your receiver uses an AE title like ENTERPRISE_ARCH, a scanner with an 8-character limit truncates the value to ENTERPRI. The association negotiation fails because the names do not match. Always test new modality integrations with short alphanumeric AE titles first.

AE titles in modern cloud architectures

When moving imaging data from hospital scanners to cloud services, you bridge two different networking models. The hospital equipment expects a classic DICOM listener with a specific AE title and port. Cloud applications prefer standard HTTP webhooks and REST endpoints.

For example, a cloud service can receive instances as standard HTTP POST requests using DICOMweb STOW-RS instead of managing a stateful DIMSE association. To understand how web-native protocols compare to classic DICOM message handling, read our comparison of DICOM C-STORE vs DICOMweb STOW-RS.

When connecting to a cloud gateway, the hospital needs standard DICOM connection details: a target hostname, port, and Called AE title. Dicomly endpoints provide a standard Called AE title (such as DICOMLY) alongside mutual TLS client certificates.

This lets hospital scanners connect using native DICOM settings while your cloud backend receives deliveries over standard HTTPS. Learn more in our guide to connecting a DICOM sender or explore receiving DICOM from a hospital over the internet.