Ir al contenido principal

How to Gather Diagnostics for Support

When an article says "note the error" or "send this to support," here's exactly how to get each piece. Gathering these before you contact support is the single biggest thing that shortens a ticket.

Protect patient privacy: what not to send

Whenever you screenshot or copy anything, identify studies by accession number. Blur or crop out patient names, dates of birth, and other identifying details.

Raw logs and config files can contain patient data and credentials. Share log excerpts and any file by attaching them directly to your open support ticket/portal case (not as an email attachment), or handing them over during the live remote session - never over plain email - and never send config files like appsettings.json (they hold access tokens).

The accession number​

The accession number is the safe, unique way to identify a study to support. Find it on the study in the Worklist (the Accession column) or in the study/order details. Use it instead of the patient's name.

The exact error message​

Type out or screenshot the full message, word for word - the wording (and any code like AADB2C90047 or DCM_ASSOCIATION_FAIL) is often what pinpoints the cause. A cropped "it said error" costs a round-trip. See Error Messages A-Z for what common ones mean.

The browser console (for viewer, login, or "blank screen" issues)​

Many web-app problems show their real cause in the browser console. OmegaAI supports Chromium-based browsers only (Chrome, Edge, Opera), so these are the only steps you'll need:

  1. Press F12 (Cmd+Option+I on a Mac, or right-click the page and choose Inspect).
  2. Click the Console tab.
  3. Reproduce the problem, then screenshot any red error lines.
  4. The Network tab shows failed requests (red / status 4xx-5xx) - useful for "it won't load" cases.

Clearing cached site data​

When an article says to clear the cache or site data for OmegaAI (Chrome, Edge, or Opera):

  1. Open OmegaAI, then click the site information icon immediately to the left of the web address. Its appearance varies by browser and version - current Chrome shows a sliders ("tune") icon rather than the padlock older guides describe - but it's always the icon in that position.
  2. Choose Cookies and site data, then Delete data. Some versions route this through Site settings instead. Either path clears cookies, cache, and local storage for OmegaAI only, without touching your other sites.

If you can't find that icon, the same control is in the browser's menu (the three-dots button, top-right) under Settings: search the settings page for "site data", open the list of all sites (Chrome calls it View permissions and data stored across sites), find omegaai.com, and delete its data.

A private/incognito window is a quick way to test whether cached data is the cause before clearing anything - the site starts with no cached data.

Date, time, and time zone​

Note when it happened with your time zone (for example, "2:15 PM ET"). Support correlates this against server logs, and the time zone matters because the logs are in UTC.

OmegaAI's built-in logs​

OmegaAI keeps activity logs inside the app that you can check yourself - often the fastest way to confirm whether something was sent or received before opening a ticket. In the left-side navigation panel (hamburger icon, top-left), click Logs. The DICOM Log opens by default; to switch to a different type, click the blue round selector button in the bottom-right corner of the Logs screen. Depending on your role's permissions, you'll typically find:

  • DICOM log - study send/receive activity, and where you confirm whether a transfer failed. Failed and rejected send tasks show small replay / cancel controls right in the log: replay re-queues that same task, which is fine after a brief outage. If a replayed task fails again, send the study fresh from the Worklist (Send > Send Study) instead - a fresh send queues the study's complete current image set, which resolves cases a replay doesn't.
  • HL7 log - outbound interface messages only (reports going out). Inbound messages from your EMR/HIS, including rejected orders, do not appear here.
  • Email log - invitation, notification, and Blume email delivery (filter by the recipient's email address).
  • SMS log - outbound SMS delivery status (e.g., appointment reminders sent by text).
  • Notification log - in-app / Blume notification delivery status.
  • Audit log - a record of actions taken by users, services, and internal processes, useful for confirming who changed what and when. What it captures depends on your configuration, so check with support if you need to rely on it for a specific event.
  • Activity History - your own personal record of actions you've taken - useful for confirming exactly what you did before reporting an issue.
  • Fax / distribution log - outbound fax and report-distribution status and error codes.

These in-app logs are safe to view and to reference by accession number. If you can find the relevant entry, note the accession, the timestamp, and any status or error shown - that's usually enough for support to act. (These are different from the on-premise OmegaAI Link file logs described next, which are for IT and can contain credentials.)

For Link and DICOM transfer issues, from the on-premise Link machine:

  • Service state: Windows Services > RamSoft Omega AI Link Service (note if there are numbered instances for multiple Links).

  • Link version: in the install folder (default C:\Program Files\RamSoft.OmegaAILink, with a numbered suffix such as _2 if the machine runs several Links), right-click RamSoft.OmegaAILink.exe > Properties > Details tab - the Product version there is what support needs. The Link installs as a Windows service, so don't expect to find it in the Settings > Apps list. Do not open or send appsettings.json or other config files; they contain the Link's access token.

  • Crash details: Event Viewer > Windows Logs > System, filter by source Service Control Manager; and Application for .NET runtime errors. Note the error codes.

  • Link logs: the logs folder under the install directory, by default C:\Program Files\RamSoft.OmegaAILink\logs - the install location can be customized at setup, so confirm the actual path with your IT team if it's not there. Log files can be huge: grab only the entries around the time the problem happened (with your time zone), not the whole file, and share them the same way as any log excerpt (attached to your ticket or during the remote session, never plain email).

  • Remote access: almost every Link fix needs a remote session with local administrator rights. RamSoft typically uses Splashtop SOS - on the affected machine, go to sos.splashtop.com, download and run the small SOS app, and give the session code it generates to support so they can connect. Running it ahead of time saves a step.

    Security warning: only start a remote session on a case you opened

    Set up remote access only for a support case you raised, through your organization's own known support channel. Never download a remote-access tool or hand out a session code because someone contacted you unprompted claiming to be from RamSoft or IT, that is a common social-engineering technique. If you didn't initiate the contact, hang up and call your usual support number.

A clean screenshot​

Capture the whole window so support sees context, then blur or crop any patient-identifying information before sending. On Windows, use Win+Shift+S to snip, then annotate; on a Mac, use Cmd+Shift+5 (its markup tools can blur before saving).