What is Study Status?
Study Status in OmegaAI represents the lifecycle of a radiology study within the system. It indicates the progress of a study from initial request to final reporting and archiving. Each status is associated with specific workflow steps and transition rules to ensure smooth operation within radiology workflows.
The Study Status feature in OmegaAI ensures that radiology workflows function smoothly by enforcing predefined study progression rules, transition values, and workflow mappings. Proper handling of study statuses prevents workflow disruptions and ensures traceability via audit logs. Administrators can customize statuses within defined constraints while ensuring compliance with radiology workflow best practices.
What are Workflow Steps?
A Workflow Step defines a stage in the radiology process that corresponds to specific study statuses. Workflow steps are used to categorize and track the study's progress from request to completion.
Study Status & Workflow Step Mapping
Study statuses are mapped to workflow steps to maintain consistency and compliance with radiology workflows. This mapping ensures that each study follows a predefined sequence of statuses.
How Mapping Works
Each study status is associated with one or more workflow steps.
When a study progresses to a new workflow step, its status updates accordingly.
Transition rules (min/max values) define the allowable movement between statuses to prevent unintended workflow disruptions.
Study Status Values & Transition Rules
Study statuses have predefined values, along with transition minimum and maximum values. These values dictate how studies move between statuses. Currently, study statuses can be marked inactive even if they are mapped to a workflow step. Every study status transition against its Transition Min and Max values.
Note:
Transition min/max rules apply in the Worklist and Study Information pages.
Transition Min and Max values apply only to manual updates (not for automated updates via Workflow Automation, DICOM ingestion, or appointment sync).
| Study Status | Description | Study Status Value | Transition Min | Transition Max |
|---|---|---|---|---|
| REQUESTED | Study has been requested via Blume or an external source | 15 | 30 | 85 |
| ORDERED | Study has been ordered, yet no study date or time has been set | 20 | 30 | 70 |
| SCHEDULED | Study has been scheduled; therefore, it has a set date and time | 30 | 40 | 85 |
| CONFIRMED | Study has been confirmed with the patient | 50 | 70 | 105 |
| ARRIVED | Patient has arrived at the clinic for the study | 70 | 80 | 120 |
| CANCELLED | Study has been cancelled | 80 | 0 | 0 |
| NO SHOW | Patient failed to arrive for their appointment | 85 | 0 | 0 |
| READY FOR SCAN | Patient has completed check in and is ready for the technologist | 90 | 100 | 105 |
| STARTED | Technologist has started the exam | 100 | 105 | 120 |
| EXAM COMPLETED | It indicates that the study was completed, and this status can now be used after the status “COMPLETED” as a triggering status | 105 | 110 | 130 |
| EXAM DISCONTINUED | Exam may have begun but had to be discontinued due to various reasons (e.g. patient was claustrophobic) | 110 | 0 | 0 |
| INPROGRESS | Images from the study are actively being received in the PACS | 115 | 120 | 160 |
| COMPLETED | All images have been received in the PACS (i.e. no pending receival) | 120 | 130 | 170 |
| IMPORT | Studies that are being manually or automatically imported into the PACS system from an external source (e.g. DICOM files, images, folders, etc.) | 125 | 0 | 0 |
| HOLD | Study is awaiting a task (prior requested/additional images etc.) | 130 | 140 | 160 |
| REJECTED | Study has been rejected due to various reasons (such as low-quality images) | 140 | 0 | 0 |
| VERIFIED | Study has been validated by a tech/end user, and it is ready for the interpreting MD to read | 160 | 170 | 200 |
| TO BE AMENDED | Study has a final report but needs an addendum | 170 | 180 | 200 |
| DICTATED | Study status in a transcriptionist workflow to indicate the reading MD has recorded their findings | 180 | 190 | 200 |
| TRANSCRIBED | Study status in a transcriptionist workflow to indicate the Transcriptionist has typed the report and is ready for the reading MD to sign | 190 | 200 | 210 |
| SIGNED | Study has a final report SIGNED | 200 | 210 | 210 |
| PRIOR | Indicates a prior study either by outside comparison | 210 | 0 | 0 |
| UNUSED | Studies that were created or received but are not actively linked to a patient record, workflow, or reporting process | 1000 | 0 | 0 |
| QA/QC | Studies that are under review for quality assurance or control purposes before they are made available for clinical use | 1100 | 0 | 0 |
How Order Status is Derived
An Order's status is not set by hand. OmegaAI derives it from the statuses of the studies on that Order, and re-evaluates it every time one of those studies is updated.
| When the active studies on the Order are… | The Order becomes |
|---|---|
| all SIGNED | completed |
| all HOLD | on-hold |
| all CANCELLED | revoked |
| any study reaches PATIENT ARRIVED | a draft Order becomes active |
If work is still outstanding — for example one study signed and another still in progress — the Order is left as it is.
Note:
The same status can look different depending on where you are viewing it. The Order panel on the Visit / Order / Study page shows it in upper case (ON-HOLD), while the Worklist column shows it as stored (on-hold). Both refer to the same status.
Studies that do not hold an Order open
CANCELLED and PRIOR studies are excluded from the count:
-
Cancelling a study is not the same as deleting it — the study stays on the Order. It is not outstanding work, so an Order with one signed study and one cancelled study still reaches completed.
-
PRIOR sits past SIGNED in the workflow; it is where a signed study moves to. A study at PRIOR does not hold its Order open.
Workflow step names must match exactly
The rules above are resolved by workflow step name, for each organization — never by study status value or transition range, because those are configurable and differ between sites. The five step names OmegaAI looks for are SIGNED, CANCELLED, HOLD, PATIENT ARRIVED and PRIOR.
Note:
The study status listed above as ARRIVED (value 70) corresponds to the workflow step named PATIENT ARRIVED. A workflow step named only "ARRIVED" will not be matched.
If an organization has no SIGNED workflow step, its Orders will never reach completed. When Orders are not completing as expected, check the organization's workflow steps first.
Things to know
-
A finished Order re-opens if its work resumes. Moving a study on a completed or on-hold Order back to an in-progress status returns that Order to active. Updating a study to SIGNED or CANCELLED does not re-open the Order.
-
Existing Orders are not updated retroactively. An Order whose studies were all signed before this behaviour was introduced keeps its current status until one of its studies is updated again.
-
Taking an Order off hold does not move its studies back. The studies stay at HOLD and are updated individually — see Update the Study Status.
-
Once an Order reaches a final status (completed, revoked, or entered-in-error), later changes to patient-level coverage no longer flow down to that Order. Coverage already recorded on the Order is unchanged.
Study Status Stamping
Study Status Stamping is the process when a study is received into OmegaAI (via DICOM Ingestion, OmegaAI Link, or Manual Import), the system evaluates several inputs to determine the correct Study Status.
Order of Preference
Since multiple mechanisms can assign or change the Study Status, OmegaAI applies them in a strict Order of Preference to ensure consistent, predictable behavior.
The higher the number, the stronger the priority (5 overrides 4, etc.):
| Priority | Source / Mechanism | Description |
|---|---|---|
| 1 (Lowest) | DICOM Metadata | Default Study Status derived from incoming DICOM tag(s). |
| 2 | Receive Status As | Explicit status provided at the time of study ingestion via device. |
| 3 | Always Overwrite Study Status | Global/station-level configuration to override incoming statuses. |
| 4 | Auto-Prior | Automatically marks studies as "PRIOR" based on configurable age thresholds. |
| 5 (Highest) | Workflow Automation / Scripting | Custom rules or scripts applied during ingestion; overrides all other statuses. |
Example Scenarios – Using OmegaAI’s Study Statuses
| Scenario | Final Study Status (What the user will see) | Why |
|---|---|---|
| DICOM metadata says SCHEDULED; no other settings applied | SCHEDULED | Default status derived from incoming DICOM metadata (Priority 1). |
| DICOM metadata says SCHEDULED; “Receive Status As” = CONFIRMED at import | CONFIRMED | “Receive Status As” overrides DICOM metadata (Priority 2). |
| Always Overwrite Study Status = COMPLETED; “Receive Status As” = CONFIRMED | COMPLETED | Station configuration overrides “Receive Status As” (Priority 3). |
| Always Overwrite Study Status = COMPLETED; study older than Auto-Prior threshold (e.g. 45 days) | PRIOR | Auto-Prior logic overrides Always Overwrite (Priority 4). |
| Study older than Auto-Prior threshold; WFA scripting rule = “If Modality=CT then status=VERIFIED” | VERIFIED | Scripting overrides Auto-Prior (Priority 5). |
Important Notes
-
If no other configurations are made, the incoming DICOM status (like SCHEDULED, STARTED) remains.
-
“Receive Status As” overrides the DICOM-supplied status (e.g. SCHEDULED → CONFIRMED).
-
“Always Overwrite” overrides both but is still overridden by Auto-Prior.
-
Auto-Prior will always stamp PRIOR when a study is older than the threshold, even if the station default is something else.
-
Workflow Automation / Scripting can set any status (such as VERIFIED, TO BE AMENDED, REJECTED, HOLD) and always overrides.