MAJWARE
DICOM10 min read

10 Most Common DICOM Errors and How to Fix Them

The DICOM errors that appear most frequently in production PACS environments — with exact causes, log signatures, and step-by-step fixes. From association rejections to transfer syntax failures and MWL mismatches.

Majware Team·18 February 2026

DICOM errors in production PACS environments fall into predictable patterns. The underlying causes are well-understood; the challenge is diagnosis speed under pressure.

This article catalogues the 10 error types that appear most frequently in real deployments — what causes them, what they look like in the logs, and exactly how to fix them.

Error 1: Association Rejection — AE Title Not Recognised

What you see: Modality fails to send studies. Technologist gets an error on the modality console ("Connection refused" or "Store failed"). Studies pile up in the modality send queue.

PACS log signature:

WARN  [DICOM] Received association request from 192.168.10.45
      Called AE Title:  PACS_MAIN
      Calling AE Title: CT_SCANNER_01
      Result: REJECTED (Reason: Calling AE not recognised)

Cause: The PACS has been configured to only accept connections from known (whitelisted) AE Titles. The calling AE Title on the modality (CT_SCANNER_01 in the example) doesn't match what's registered in the PACS AE Title table. This is almost always a typographical mismatch or a case sensitivity issue.

Fix:

  1. Identify the exact AE Title configured on the modality (check the modality's DICOM configuration screen)
  2. Compare character-by-character with the PACS AE Title registry — note that AE Titles are case-sensitive
  3. Correct the mismatch in either the modality configuration or the PACS AE registry (prefer correcting the PACS registry to avoid modality downtime)
  4. Retry the association

Prevention: During go-live prep, print the AE Title from the modality DICOM screen and copy it — don't type it by hand into the PACS registry.

Error 2: Association Rejection — Called AE Title Not Recognised

Similar to Error 1, but the direction is reversed.

What you see: Same symptom — modality cannot send. But the log shows a different rejection reason.

PACS log signature:

WARN  [DICOM] Received association request from 192.168.10.45
      Called AE Title:  PACS_STOR
      Calling AE Title: CT_SCANNER_01
      Result: REJECTED (Reason: Called AE not recognised)

Cause: The modality is sending to a destination AE Title (PACS_STOR) that doesn't exist in the PACS. The PACS has its storage SCP registered under a different name (e.g., PACS_MAIN).

Fix: Correct the destination AE Title on the modality to match the PACS storage SCP AE Title exactly.

Error 3: Presentation Context Rejection — Transfer Syntax Mismatch

What you see: Association is accepted, but no images are transferred. Modality reports "Send failed" or "No acceptable presentation context". Studies remain unsent.

PACS log signature:

INFO  [DICOM] Association accepted from CT_SCANNER_01
WARN  [DICOM] All presentation contexts rejected for CT storage SOP class
      Proposed: 1.2.840.10008.1.2.4.70 (JPEG 2000 Lossless)
      Proposed: 1.2.840.10008.1.2.4.51 (JPEG Baseline)
      Proposed: 1.2.840.10008.5.1.4.1.1.2 (CT Image Storage)
      Result: No acceptable transfer syntax found

Cause: The modality and PACS could not agree on a transfer syntax for the CT Image Storage SOP class. The modality proposed only JPEG 2000 and JPEG Baseline encodings; the PACS only accepts Explicit or Implicit VR Little Endian for CT.

Fix options (in order of preference):

  1. Configure the PACS to accept the transfer syntaxes the modality proposes (usually the correct fix for modern modalities)
  2. Configure the modality to also propose Explicit VR Little Endian (1.2.840.10008.1.2.1) — most modalities support this as a fallback
  3. If the modality is very old and only supports Implicit VR Little Endian (1.2.840.10008.1.2), add this transfer syntax to the PACS accepted list

Diagnostic tip: Run the free Majware DICOM Header Validator against a test DICOM file from this modality — it will show you the transfer syntax used in the file, which tells you what the modality natively produces.

Error 4: Missing or Incorrect Accession Number

What you see: Studies arrive in PACS but cannot be matched to a worklist entry. Studies appear as "unscheduled" or with no patient demographics. Radiologists see "unknown patient" studies in their worklist.

DICOM tag to check: (0008,0050) Accession Number

Cause: The accession number in the DICOM header doesn't match any worklist entry in the PACS. Common causes:

  • HL7 ORM message created the worklist entry with accession number 2026021400123; the modality sent the study with accession number 21400123 (truncated on an older modality with an 8-character limit)
  • Manual studies acquired without a worklist entry (no accession number populated)
  • The modality's character limit for accession number is shorter than your RIS-generated format

Fix:

  1. Check the DICOM header of the affected study — use the PACS audit log or a DICOM viewer to read tag (0008,0050)
  2. Compare with the worklist accession number for the expected patient
  3. If the accession number was truncated, this is a configuration issue — either shorten your RIS accession number format or use a modality that supports longer accession numbers
  4. For immediate fix: manually reconcile the study using the PACS administrative tools (patient/study management module)

Error 5: Modality Worklist Returns Empty — C-FIND Issue

What you see: Worklist button on the modality shows no patients, even when scheduled procedures exist in the RIS for today.

Cause candidates:

  • Date/time filter mismatch
  • Scheduled Station AE Title filter
  • AE Title restriction on the MWL SCP
  • HL7 ORM not received by PACS (interface issue upstream)

Diagnostic approach:

First, confirm the worklist entry exists in the PACS — look in the PACS administrative interface for the expected patient/procedure. If it's not there, the issue is in the HL7 ORM pipeline, not the DICOM MWL.

If the worklist entry exists in PACS, capture the C-FIND request from the modality. Most PACS systems have a DICOM transaction log that shows the C-FIND RQ attributes:

C-FIND RQ from CT_SCANNER_01:
  (0008,0060) Modality: CT
  (0040,0001) Scheduled Station AE Title: CT_SCANNER_01
  (0040,0002) Scheduled Procedure Step Start Date: 20260218

The most common hidden cause: the C-FIND request includes a Scheduled Station AE Title filter, and the worklist entry in PACS has a different or blank station AE Title. Either populate the scheduled station AE Title on worklist entries to match the modality, or configure the MWL SCP to return results regardless of station AE Title.

Error 6: Patient Demographic Mismatch — Wrong Name in DICOM Header

What you see: Study arrives with incorrect patient name or MRN. The patient name in the DICOM header (0010,0010) doesn't match the patient in the worklist.

Cause: The modality used manual patient entry instead of worklist retrieval, or the worklist demographic was populated incorrectly upstream (ADT issue).

The patient safety risk: This is not just an IT problem. Studies associated with the wrong patient create clinical risk. Establish a formal workflow for demographic corrections.

DICOM tags to verify for every patient mismatch investigation:

  • (0010,0010) Patient's Name
  • (0010,0020) Patient ID (MRN)
  • (0010,0030) Patient's Birth Date
  • (0008,0050) Accession Number

Fix process:

  1. Do not delete the study
  2. Use PACS patient management tools to associate the study with the correct patient record
  3. Investigate root cause: was worklist bypassed? Was the ADT message incorrect?
  4. If systematic (multiple occurrences), audit your ADT→RIS→MWL pipeline for the affected patient population

Error 7: DICOM C-STORE Failure — Storage Full

What you see: Studies fail to store. PACS event log shows storage errors. Modality send queues accumulate.

PACS log signature:

ERROR [Storage] C-STORE failed for study 1.2.840.113704.1.111.2345.xxx
      Reason: Unable to write to storage tier FAST_SSD
      Detail: Disk quota exceeded (97.3% full)

Cause: Fast-tier storage (typically SSD cache) is full. This can happen faster than expected if study volumes spike (e.g., a multi-trauma event generating large CT datasets) or if automated migration from fast-tier to near-line storage has failed.

Immediate fix:

  1. Identify and trigger manual migration of oldest studies from fast-tier to near-line storage
  2. Monitor until fast-tier drops below 80% utilisation
  3. Verify modality send queues clear

Root cause fix:

  1. Investigate why automated tiering failed — check migration job logs
  2. Review fast-tier capacity against current study volume — may be undersized
  3. Set up monitoring alerts at 70% and 85% utilisation (not just at 95%)

Error 8: HL7 ORM Parsing Error — Procedure Code Not Found

What you see: HL7 orders arrive at PACS interface, but no worklist entries are created. Interface engine shows messages as "processed" but PACS has no record.

PACS log signature:

WARN  [HL7] ORM O01 received - Order NW
      Patient: SMITH^JOHN^A / MRN: 123456
      Accession: 2026021800456
      Procedure code: CT-CHEST-PE
      Result: FAILED - Procedure code 'CT-CHEST-PE' not found in procedure dictionary

Cause: The procedure code sent in OBR-4 of the ORM message doesn't match any code in the PACS procedure dictionary. This is a mapping problem — the RIS and PACS use different procedure code systems.

Fix:

  1. Identify the procedure code format the PACS expects (check the PACS procedure dictionary)
  2. Build a mapping table between RIS procedure codes and PACS procedure codes
  3. Implement the mapping in your interface engine (transform the code in OBR-4 before delivery to PACS)
  4. For immediate relief: manually add the unrecognised code to the PACS procedure dictionary as a mapped alias

Prevention: During implementation, extract the complete procedure code list from both RIS and PACS and reconcile them before go-live. This mapping work is a prerequisite for interface testing, not an afterthought.

Error 9: Duplicate Study — Same Study Received Twice

What you see: PACS shows two copies of the same study. One may have correct demographics; one may not. Radiologists are uncertain which is the authoritative study.

Cause: The modality sent the study twice — either due to a retry after an apparent (but actually successful) first send, a network timeout that caused a retry, or manual re-send by the technologist.

How DICOM should handle this: DICOM defines Study Instance UID (0020,000D) and SOP Instance UID (0008,0018) to uniquely identify studies and individual images. If the PACS is correctly configured, a second C-STORE of the same SOP Instance UID should update the existing record, not create a duplicate.

The problem: Some PACS systems and some send configurations create new UIDs on retry. Some PACS systems create duplicate entries rather than updating.

Fix:

  1. Use the PACS patient/study management tools to merge or delete the duplicate
  2. Verify which study has complete and correct data before deleting
  3. Investigate: is the modality generating new Study Instance UIDs on retry? This is a misconfiguration on the modality side.

Error 10: DICOM TLS Handshake Failure

What you see: Modality cannot connect to PACS even though AE Titles and IP/ports are configured correctly. This typically appears after a server SSL certificate renewal.

PACS log signature:

ERROR [DICOM-TLS] TLS handshake failed with 192.168.10.45
      Reason: SSL_ERROR_RX_RECORD_TOO_LONG
      — or —
      Reason: Certificate verification failed (certificate expired)

Cause: One of three things: expired certificate, cipher suite incompatibility, or the modality is configured for plain DICOM on port 104 but the PACS is expecting TLS on port 2762 (or vice versa).

Fix:

  1. Check certificate expiry date on both PACS server certificate and the CA certificate used by the modality
  2. Verify port configuration: DICOM plain = 104, DICOM TLS = 2762 (or your configured TLS port). Mismatch is a common post-maintenance error.
  3. If cipher suites are the issue, this is a modality firmware limitation — check whether a firmware update resolves it, or configure the PACS TLS listener to accept the cipher suite the modality requires

Using the DICOM Header Validator

For errors 3, 4, and 6 in particular, being able to inspect the actual DICOM header of a test file speeds diagnosis significantly. The free Majware DICOM Header Validator (no signup required) lets you upload a DICOM file and instantly inspect all tags — including the transfer syntax, patient demographics, and accession number — without installing any software.

Bookmark it for go-live day. When a modality is failing to send, having the DICOM header in front of you tells you within 60 seconds whether the problem is in the header data or the network association layer.

#DICOM#troubleshooting#PACS#error codes#AE Title#transfer syntax