Skip to main content

DICOM and Image Transfer Issues

Problems sending studies from modalities to OmegaAI, sending to other PACS, and keeping OmegaAI Link healthy. These entries reflect the most common causes RamSoft Support sees, in order of likelihood.

Symptoms

  • The Link status indicator shows offline/red in OmegaAI
  • Studies sent from modalities never arrive; sends stay stuck in Requested in the DICOM logs
  • Often starts after a power outage, a Windows update, or overnight

Where to look

  • Link status: in OmegaAI, go to Organization Details > Device - each Link/device shows online (green) or offline (red).
  • Transfer state: the DICOM log shows studies stuck in Requested when the Link can't forward them.
  • On the Link machine: the service is in Windows Services as RamSoft Omega AI Link Service; crash details are in Event Viewer > Windows Logs > System (filter source Service Control Manager) and Application; the Link's own logs are under its install folder (C:\Program Files\RamSoft.OmegaAILink\logs).

Likely causes

  1. The Link service on the on-premise machine has stopped (most common after power outages or unclean shutdowns)
  2. A Link auto-update failed, leaving the service crash-looping
  3. Antivirus/EDR software is blocking the Link (see Antivirus and EDR Exclusions)
  4. The Link machine lost network connectivity

What to try (requires local administrator rights on the Link machine)

Note: this fix spans two systems

Steps 1, 2 and 5 happen on the Link machine (Windows). Steps 3 and 4 happen in OmegaAI (the web app). Whoever has access to the Link machine often doesn't have an OmegaAI login and vice versa, so line up both before you start, or agree who does which half.

  1. Confirm the Link machine is powered on and has internet access (open any external website in a browser).
  2. Open Windows Services and find RamSoft Omega AI Link Service. If it is stopped, start it; if it is running but the Link still shows offline, restart it. There's no need to restart a Link that's working, but doing so doesn't corrupt anything: transfers interrupted by a restart return to the queue and are picked up again when the service comes back.
    • On a machine hosting more than one Link, the services are numbered (...Service, ...Service 2, ...Service 3, and so on). Make sure you start the correct instance for the affected Link, and after an update restart all of them, not just the first. Auto-updates run silently in the background with no visible indicator, so you generally won't see one happening; if support tells you an update went out, or you notice the Link version changed, treat that as the signal to restart every instance on the machine.
  3. Back in OmegaAI, confirm the Link shows Online, then run Test Connection on the affected station entry.
  4. Failed transmit tasks retry automatically (12 attempts) before being marked Rejected, so a brief outage often clears on its own once the Link is back online. Check the DICOM log (left-side navigation panel > Logs, DICOM Log is the default view; see OmegaAI's built-in logs) to see which studies actually ended up Rejected, then re-send those from the Worklist with Send > Send Study. That's mainly needed for studies already showing Rejected, or if the Link service itself was down while the retries would have happened.
  5. If the service stops again by itself, it's crash-looping, this can follow a failed update, but a plain service stop (a reboot, a Windows update) or a brief network interruption at startup can trigger the same signature. Check Windows Event Viewer for .NET Runtime Event 1026 or Service Control Manager 7031 entries mentioning the Link. This needs a fix from RamSoft Support - do not repeatedly restart.
Checklist: if you need to contact support, send this

Having these ready turns a multi-day Link ticket into a single session:

  • The Link/device name and the customer/site it serves
  • When it went offline and what changed on the machine around then (Windows update, antivirus/EDR change, power event, reinstall)
  • The Link version - right-click RamSoft.OmegaAILink.exe in the install folder (default C:\Program Files\RamSoft.OmegaAILink) and check Properties > Details > Product version; do not send the appsettings.json or other config files, they contain the Link's access token
  • Any Event Viewer error codes (e.g. .NET Runtime 1026, Service Control Manager 7031), and the latest Link log lines from around the time it happened - share logs via a secure channel or the remote session, not unredacted email (they can contain patient details and credentials)
  • Whether it hosts multiple Links, and which instance is affected
  • Remote access with local admin rights arranged in advance (RamSoft uses Splashtop SOS, see Gathering Diagnostics) - almost every Link fix needs it

If the Link machine restarts (Windows update, power event) and the service does not start on its own even though it is set to Automatic:

  1. In Windows Services, open the service's properties and set startup type to Automatic (Delayed Start), then reboot and test. The Link depends on the network stack being up, and plain Automatic can lose that race at boot.
  2. If it was recently installed or reinstalled, confirm the installer was run as Administrator - a non-elevated install is a common cause of a service that won't start.
  3. If it still won't start, open Event Viewer (Windows Logs, System) and filter by source Service Control Manager around the reboot time; note the error code for support.

Worth setting as an expectation with your IT/on-call staff: after any power outage, restarting the RamSoft Omega AI Link Service is the correct first response before contacting support.

Test Connection to a station fails​

Symptoms

  • The Link is online, but Test Connection to a specific modality or PACS fails
  • A modality cannot pull the worklist (MWL); the modality shows a connection-refused error

Where to look: run Test Connection from the station entry in OmegaAI (Organization Details > Device). The result is a simple Connection Succeeded or Connection Failed message - it doesn't show the IP, port, or a specific cause, so treat a failure as a prompt to check each likely cause below directly, rather than something to diagnose from the message itself.

Likely causes

  1. Enable TLS is turned on for a station that does not support TLS
  2. A local firewall is blocking the DICOM port on the Link machine
  3. The modality's IP address changed (common after network equipment changes)
  4. The Link machine was replaced or re-addressed and modalities still point at the old destination

What to try

  1. Check the station entry's Enable TLS setting - if the destination does not support TLS, disable it, restart the Link service, and retest.
  2. Ask IT to confirm the DICOM port (commonly 104 or the port configured for your Link) is allowed through the local firewall on the Link machine.
  3. Verify the modality's current IP address matches the station configuration - ping it from the Link machine.
  4. Give the Link machine a static IP or DHCP reservation so modalities never lose their destination after a reboot.

Still stuck? Capture the exact error from the modality's console and the station's configured AE title, IP, and port.

Worklist connects but returns no studies or the wrong studies​

If the modality connects to the worklist without error, but the modality returns no results (or the wrong results) for a patient/order you know exists:

  1. Scheduled Station AE Title mismatch: the station's configured AE title in OmegaAI must exactly match what the modality sends as its Scheduled Station AE Title (case and whitespace sensitive). A mismatch silently filters out all matching worklist entries even though the connection itself succeeds. Compare the two values character-for-character.
  2. Modality date/time misconfiguration: worklist queries are date-scoped, if the modality's system clock or date is wrong, the query returns zero results for "today" even though studies exist. Verify and, if needed, sync the modality's date and time.

Check both of these first before assuming the order or the worklist entry itself is missing.

Transfers are slow, or studies arrive with missing images​

Symptoms

  • Studies take much longer than usual to appear
  • The image count is lower than what the modality sent, then catches up slowly

Likely causes

  1. A queue backlog is draining after the Link was offline
  2. Low disk space on the Link machine (transfers throttle, then stop)
  3. Antivirus scanning the Link's image folders (very common and easy to miss)
  4. A very large study (tomosynthesis, long CT) ahead in the queue, or limited upload bandwidth

What to try

  1. Check free disk space on the drive holding the Link's image folders. Where the automatic alert is enabled for your site, the Link notifies configured admins by email once a drive is more than 80% full (less than 20% free), treat that as the real warning line rather than waiting until space is critically low, regardless of whether the alert is active for your organization.
  2. Confirm AV exclusions cover the Link folders on the drive where they actually live - a recurring miss is folders moved to a data drive while exclusions still point at C:. See Antivirus and EDR Exclusions.
  3. After an outage, allow the queue to drain before investigating individual studies.
  4. If consistently slow, run a bandwidth test from the Link machine and share the result with support.

Still stuck? Report the queue depth, how long items have been queued, free disk space, and your measured upload bandwidth.

Sends to another PACS keep failing or get rejected​

Symptoms

  • Studies to a reading group or external PACS fail repeatedly; tasks show Rejected after multiple attempts
  • The DICOM log shows DCM_ASSOCIATION_FAIL

Likely causes

  1. The receiving PACS limits how many simultaneous DICOM connections it accepts, and refuses extras
  2. The receiving side does not recognize your AE title, or aborted the association
  3. The receiving system is offline
  4. The receiving system rejects the images themselves due to an unsupported SOP Class or transfer syntax, or a corrupt/incomplete file (Link logs show DCM_NOTSUPPORT_PROPOSED_CONTEXT or DCM_CANNOTCOMPRESS, distinct from DCM_ASSOCIATION_FAIL)

What to try

  1. Ask the receiving PACS administrator to check their inbound association limit and whether your AE title and IP are allowlisted.
  2. After the receiving side is fixed, re-send the rejected studies - rejected tasks do not retry on their own. Prefer sending from the Worklist (select the studies, then Send > Send Study) over the replay button in the DICOM log: replay re-queues the same task as-is, while a fresh send queues the complete current set of images, which succeeds in cases where a replay doesn't.
  3. See Error Messages for what DCM_ASSOCIATION_FAIL means (and why DCM_ASSO_TIMEOUT in logs is not an error).
  4. If the log instead shows DCM_NOTSUPPORT_PROPOSED_CONTEXT or DCM_CANNOTCOMPRESS, the association succeeded but the receiving system rejected the images themselves, ask the receiving PACS administrator to confirm which SOP Classes and transfer syntaxes they support, and check the study for a corrupt or incomplete file.

Still stuck? Mention the receiving vendor's association limit when you contact support, along with the AE title and any error codes seen.

A study arrived at the destination under the wrong patient or accession​

Symptoms

  • The reading group reports a study filed under the wrong patient or split into two studies
  • A study "never arrived" but actually exists filed as a prior

Likely causes

  1. The order was corrected in the RIS after the modality had already pulled the worklist entry, so images carried the old accession
  2. Images arrived before (or without) a matching order, creating a split study
  3. The destination PACS filed an old-dated study as a prior automatically

What to try

  1. Train technologists to refresh the modality worklist after any order change before acquiring.

  2. For split studies: in the main Worklist grid, select both study cards, then right-click and choose Link & Merge > Merge Studies to open the merge drawer. This is a manual action you take, OmegaAI does not flag duplicates for you. Merge Studies only offers itself when the selected studies belong to the same patient and the same managing organization.

    Patient safety: verify before you merge

    Before merging, confirm the patient name, date of birth, and a third identifier (Patient ID, address, or phone) all match. Merge does not re-verify this for you, and there is no self-service undo: a Split study control exists, and RamSoft can help unwind a wrong merge, but recovery may not restore everything downstream (reports, distributions, sends already made to other systems). Verifying first is far cheaper than recovering.

    If Merge Studies doesn't appear at all, the usual reason is that the selected studies belong to different patients. That's a deliberate guardrail against a wrong-patient merge, not something to escalate past. Re-check the identifiers first; if they really are the same patient in the same organization, it's a permissions issue, see Worklist actions are missing.

  3. If a study seems missing at the destination, search by patient there - it may be filed as a prior based on its study date.

Still stuck? Provide the accession number(s), the time the order was changed, and the time the study was acquired.

Hybrid PowerServer / Gateway sites​

If your site also runs PowerServer or Gateway components, their DICOM error logs are documented separately: see How can I monitor DICOM communication problems? in the PowerServer manual.