Ir al contenido principal

Workflow Automation Issues

Workflow Automation (WFA) drives auto-sends, status changes, and notifications. Most "the workflow didn't do what I expected" tickets come down to a small set of design rules rather than faults. Understanding these prevents the majority of WFA support cases.

Design rules worth knowing first​

Reference: how Workflow Automation actually behaves
  • Send Study transmits whatever image objects currently exist on the study, if none have arrived yet, there's nothing to send. A workflow that tries to pull priors and send in the same automation will not work reliably, because the actions run asynchronously and the send can fire before the priors arrive.
  • To send priors, use two workflows: one that pulls the priors, and a second that sends studies when they reach the resulting status.
  • Workflows are triggered by a specific study status. If your studies never reach that status, the workflow never runs.
  • Automations are configured per organization, not globally.

A study status changed by itself​

Symptoms

  • A signed study reverts to COMPLETED or VERIFIED, or a status changes with no user action

Likely causes

  1. Late-arriving DICOM objects recalculated the status, applying the receiving station's "Receive Study Status as" setting again. Study Locking (the locking step is set per organization under Workflow Steps > Prevent Modification, commonly PRIOR) stops people editing a study, but don't count on it to stop this: a study can still be re-stamped by what arrives afterwards, including one that was already signed. If that happens, report it with the accession number and the arrival time rather than assuming a user did it
  2. A Workflow Automation rule fired on an incoming event
  3. Your browser's real-time connection may have dropped, leaving the screen showing a stale status, refresh the page

What to try

  1. Read the study audit log first - it names the exact event and time. Most "it changed itself" reports are a rule or a user, visible there.
  2. If the status looks wrong only on your screen, clear OmegaAI's cached site data and sign in again (see Clearing cached site data).
  3. If a workflow is repeatedly moving studies you don't expect, review that automation's trigger status with your administrator.

Still stuck? Provide the accession number and the audit log entry for the status change.

An auto-send (studies or reports) didn't fire​

Symptoms

  • Studies or reports that should auto-forward on a status never went

Likely causes

  1. The send workflow triggers on a status the studies never actually reach
  2. The study had no image objects yet when the send fired (see the design rules above)
  3. The workflow is routing to a destination (OmegaAI Link/device) that is offline
  4. A condition on the workflow (e.g., modality, study type) isn't matching, so the automation reaches the trigger but takes the "No" branch, review the workflow's condition logic with your administrator
  5. You're looking at the wrong organization's rules, rules that apply to a study can live on a child organization rather than the parent you opened

What to try

  1. Confirm what status the workflow triggers on, and that the affected studies reach it.

  2. Check Workflow Automation on the affected organization and each of its child organizations, rules are easy to miss at the child level.

  3. For priors, confirm you are using the two-workflow pattern rather than pull-and-send in one.

  4. Confirm the destination device is online (see DICOM and Image Transfer Issues).

  5. To make a corrected workflow act on a study that already missed it, move the study's status out of the trigger status and back into it, which re-fires the rule.

    Warning: re-triggering re-sends everything on that rule

    Every action attached to that trigger runs again, so a study can be distributed, faxed, or notified a second time. Confirm what else is attached to the status before cycling it, and prefer doing this on one study first.

Still stuck? Provide the workflow name, its trigger status, and an example study that didn't send.

A workflow action ran more than once​

Symptoms

  • A study was sent twice, or a notification went out more than once, for the same trigger

Likely causes

  1. A retry after a partial failure re-executed the action instead of picking up where it left off
  2. Near-simultaneous duplicate trigger events (for example, two status updates arriving close together) both started the workflow

What to try

  1. Check whether the study or destination logged an error around the time of the first attempt, which would explain a retry.
  2. Note whether the duplicate happened close in time to another event on the same study.

Still stuck? Provide the accession number and the approximate timestamps of both occurrences.

A reminder or notification went out wrong (or not at all)​

See Scheduler Issues for appointment-reminder specifics. In general: notifications are driven by WFA, configured per organization, and depend on correct patient contact details.

The workflow editor is broken or a workflow won't save​

Symptoms

  • The Workflow Automation editor won't load or a saved workflow behaves as if empty

Likely cause

A blank or corrupted workflow script can break the editor. This is usually caused by a save interrupted partway through (lost connection, closed tab, or two people editing the same workflow at once) leaving a partially written definition.

What to do

This needs RamSoft to reset or repair the workflow script - contact support with the organization and workflow name. Avoid re-saving the broken workflow, which can compound the problem.

Agreeing that only one person edits a given workflow at a time is good prevention, but it won't repair a script that's already corrupted, once the editor is in this state, the fix is on RamSoft's side regardless.