Overview
OmegaAI has replaced the legacy Master Organization model with a redesigned Managing Organization hierarchy. This architectural change centralizes patient record management, introduces a consistent two-tier access control model (Split-UAC), and enables flexible order workflows across multi-site organizations.
Summary of Changes
| Area | Previous Behaviour | New Behaviour |
|---|---|---|
| Patient record storage | Created per organization | Always created & stored at Managing Org level |
| Patient UAC | Applied per originating org | Enforced at Managing Org for all hierarchy users |
| Study UAC | Varied | Enforced at Imaging Org level (Split-UAC) |
| Imaging Org at order creation | Required | Optional — floating orders supported via feature flag |
| Unassigned orders/studies | Not supported | Visible to all users in the Managing Org hierarchy |
| Payer configuration | Per org | Configured at Managing Org; shared to all child orgs |
Key Benefits
- Unified patient records — Patients are created once at the Managing Organization, eliminating cross-org duplicates.
- Clear, predictable access control — Patient access follows the Managing Org hierarchy; Study access follows the assigned Imaging Org.
- Flexible imaging assignment — Orders can be placed before an Imaging Organization is known and remain accessible to all hierarchy users until one is assigned.
- Simplified hierarchy — One top-level Managing Organization governs each organizational tree.
Organization Types & Hierarchy
Every OmegaAI deployment is structured as a tree with exactly one Managing Organization at the top. Beneath it sit Child Organizations, some designated as Imaging Organizations. Those may have their own Grandchild Imaging Organizations beneath them.
Managing Organization
The top-most organization in any hierarchy. There is exactly one per organizational tree.
- Stores all patient records for its entire organizational tree
- Acts as the central configuration hub for Roles, Study Statuses, Workflow Steps, and Payers
- Enforces Patient-level UAC for all users within the hierarchy
- Can also function as an Imaging Organization if imaging is performed at this level
Setup Note:
The Managing Organization is identified by leaving its Managing Organization parent field blank during setup.
Child Organization
Any organization sitting beneath the Managing Organization.
- Manages its own users
- Can be designated as an Imaging Organization
- Has a limited configuration set
- Inherits core resources such as Roles and Workflow Steps from the Managing Organization
Imaging Organization
Any organization — the Managing Organization itself, a Child, or a Grandchild — where imaging studies are performed.
- Manages Study-level UAC
- Optional at order creation
- Once assigned, visibility is restricted to users of that Imaging Organization only
Access Control (UAC) Model
OmegaAI uses a Split-UAC model: Patient access and Study access are governed separately.
The Two-Tier UAC Rule
| Resource | UAC Enforced At | Who Can Access |
|---|---|---|
| Patient | Managing Organization | All users in the Managing Org hierarchy |
| Study (Imaging Org assigned) | Imaging Organization | Users belonging to the assigned Imaging Org only |
| Study (no Imaging Org assigned) | Managing Organization | All users in the Managing Org hierarchy |
Patient Visibility by User Type
| User Type | Patients Visible in Search |
|---|---|
| Managing Organization user | Patients from the Managing Org and all Child Imaging Orgs |
| Child Imaging Organization user | Patients from their Managing Org and their specific Child Imaging Org |
When duplicate demographic records exist, both records are displayed with organization labels.
Patient Management
Centralized Patient Creation
All new patients — regardless of entry point — are created at the Managing Organization level. The Managing Org’s Assigning Authority is used for all patient IDs.
Applies to:
- UI order creation
- DICOM ingestion
- HL7/FHIR ingestion
- Appointment scheduling
- Walk-in registration
DICOM Ingestion – Patient Matching Logic
Patients are resolved using a top-down hierarchy search before any new record is created.
| Scenario | System Behaviour |
|---|---|
| Found in Managing Org | Reuse patient; link study |
| Found only in Child Org | Reuse Child Org patient; no duplicate |
| Not found anywhere | Create new patient at Managing Org |
| Found in both | Managing Org record takes precedence |
All resolution paths are recorded in ingestion logs.
Feature Flag Behaviour (Patient Records)
Multiple scenarios describe system behavior as the feature flag transitions from OFF to ON, ensuring consistent patient and Imaging Org handling across the hierarchy.
(Scenarios preserved exactly as provided)
Data Migration & Merging (Planned)
- Patients are merged only if Patient ID, DOB, and Original Issuer match
- Otherwise, a new patient ID is created
- Originating Imaging Organization linkage is preserved
Order & Study Management
Floating Orders
- Imaging Organization is optional
- Requires a feature flag
- Supports unknown or deferred imaging assignment
Floating Order Visibility
Floating orders appear in Worklist and Global Search for all users in the Managing Org hierarchy.
Imaging Organization Assignment
Once assigned, visibility is immediately restricted to the Imaging Organization’s users.
Order Splitting
Splitting orders across Imaging Organizations is not supported. A new order must be created.
Key User Workflows
Creating an Order
| Field | Scenario | Behaviour |
|---|---|---|
| Managing Org | Single | Auto-filled, read-only |
| Managing Org | Multiple | Mandatory selection |
| Imaging Org | Any user | Optional |
| Imaging Org | Blank | Floating order |
Appointment Scheduling
Patients are always created at the Managing Org. Imaging Org must be linked during scheduling.
Walk-in Patients
Front desk users create patients at Managing Org and assign Imaging Org at booking.
System Configuration
Organization Setup
Top-level orgs leave the Managing Organization field blank.
UAC Configuration
- Patient-level privileges → Managing Org
- Study-level privileges → Imaging Org
API & Integration Behaviour
- Patient APIs default to Managing Org
- HL7/FHIR/DICOM follow the same resolution logic
- Floating orders follow hierarchy-wide visibility rules
- Patient search APIs return unioned results
Frequently Asked Questions
A. What happens if two child organizations have patients with the same ID but different dates of birth?
They will not be merged during migration. Two separate patient records are created at the Managing Organization with unique IDs.
B. Can a user see a study if they are not part of the assigned Imaging Organization?
No. Once an Imaging Organization is assigned, study access is restricted to users of that Imaging Organization. The exception is studies without any assigned Imaging Organization — these are visible to all users in the Managing Organization hierarchy.
C. What role does a child org user use to access a floating study?
The user accesses the floating study using the role assigned to them within their Child Imaging Organization. Role-based security is preserved even for hierarchy-wide visible studies.
D. Can I split an order across two Imaging Organizations?
No. If imaging must be performed at a different Imaging Organization, a new order must be created.
E. What happens to a floating order when an Imaging Organization is assigned?
Study visibility is immediately restricted to users of the assigned Imaging Organization. Users who previously had access due to the floating status will no longer see the study in their worklist or search results.
F. How are walk-in patients handled?
The patient is created at the Managing Organization level. The Imaging Organization is assigned to the order at the time of booking by the front desk user.
G. What happens to patient ImagingOrg records created before the feature flag was enabled?
ImagingOrg is NULL for studies created before the flag was enabled. Once the flag is turned ON and a new study arrives for the same patient, ImagingOrg defaults to the relevant organization based on which device pushed the study.
``