Permissions, Roles and Organizations

A large share of "I can't see it / I can't do it / a feature is missing" reports come down to a handful of role and organization settings. Check these before assuming something is broken. Most changes here are made by an administrator in Organization > Details > Users & Roles.

The one setting that causes the most confusion: blank User Type

A role with its User Type field left blank silently disables a set of actions, even for users who otherwise look fully privileged. Symptoms include:

• Cannot sign reports (a "Reading Physician" role with no User Type set)
• Worklist right-click actions missing, including Merge / Link & Merge
• Assignment dropdowns (Reading Physician, Technologist, Care Team) showing empty or "No options"

Fix: set the role's User Type to the correct value (for example, Reading Physician or Performing Technologist). The disabled actions return immediately. This single check resolves a surprising share of "permission" tickets.

Who can see which studies (too many, or too few)

The controlling setting is Study Access, set to All Studies vs Assigned Studies. It lives inside the role itself: Organization > Details > Users & Roles, open the role, then find Study Access nested under the Worklist module (see User Access Control for how the role permission tree is structured).

• A user sees every study in the organization when they should only see their own: their role has all-studies access. Turn it off and use role worklists filtered by Reading or Referring Physician.
• A user can't see a study that's assigned to them: check the assignment fields - being listed as consulting physician counts as an assignment.
• A shared Teaching Folder went blank for colleagues: folders only show studies the viewing user can access, so restricting a role to assigned-studies-only also empties shared folders for that role.
• A referring provider sees all images instead of just their patients': use a role worklist filtered by Referring Physician.

Users, devices, or destinations "missing" after adding an organization

Symptoms

• A newly added imaging organization's devices, DICOM destinations, or users don't appear

Likely cause

The user isn't a member of the new organization, or the change hasn't been picked up by the current session.

What to try

1. Confirm the user is explicitly added to the new organization (including the correct child organization - a missing child-org assignment is the most common cause of "missing" studies, users, and destinations).
2. Sign out and back in after organization membership changes.
3. For referring organizations, remember parent/child referring orgs are shared across the hierarchy by design.

Can't deactivate a user who has roles in multiple organizations

If deactivating a user doesn't seem to take effect, or the option is blocked, remove their roles in other organizations first. A multi-org user keeps access everywhere until every role they hold is removed or deactivated, deactivating them in a single organization isn't enough on its own.

Organization Affiliation

Organization Affiliation is a separate, one-directional mechanism for giving users from one organization access to another (for example, a reading group affiliated with an imaging center). It's managed under Organization > Details > Organization Affiliation, not through the regular Users & Roles membership screen.

Affiliation on its own doesn't grant access - the per-role mapping for the affiliation must be set up explicitly, matching affiliate roles to the roles they should be able to use in the target organization. If an affiliated user still can't see anything in the other organization, check that this role mapping exists before assuming the affiliation itself is broken. For the full setup process, see Organization Affiliation.

Specific role permissions people ask about

• Merge / Unmerge studies: Image Viewer > QC Module > Merge/Unmerge Studies, and Patient > Link & Merge Patient. Missing options are usually the blank User Type above, or a genuinely unchecked permission. Both actions permanently alter patient/study identity data. Patient safety first: confirm the patient name, date of birth, and a third identifier (Patient ID, address, or phone) all match before merging, unmerge may not fully reverse all downstream effects (reports, distributions).
• Modifying a locked study: requires the Modify Locked Study permission. Which workflow step locks a study is set per organization under Workflow Steps > Prevent Modification, and it's typically PRIOR. Because it's configurable, check that setting (or ask an admin) rather than assuming. PRIOR and SIGNED are both common in practice, and the on-screen message names the status that locked the study. See Study Locking for how the lock behaves.
• Deleting reports: front-desk-type roles should usually have "Delete preliminary/final report" disabled - check this if reports are being deleted unexpectedly.

Adding a referring physician who isn't in the system yet

A referring physician must exist as a user before they can be assigned on a study. If they don't need to log in to OmegaAI, create a referring-physician account for them anyway so they're selectable. An OmegaAI login email can be edited by an administrator until the user's first login - once they've logged in, it becomes locked and a typo means creating a new account.

Duplicate NPI conflicts when adding or updating a physician

If saving a user fails with a duplicate-NPI error, that NPI already exists on a user in another organization. When creating a new user, you may see a confirmation dialog offering to add the existing profile to your organization, click Yes to resolve it yourself (this dialog depends on a setting your organization may or may not have enabled, if you don't see it, that's expected for some organizations, not a sign something's broken). If no such dialog appears and the save is simply blocked, you're likely editing an existing account rather than creating one, see A physician ended up as two separate accounts, and the NPI update is hard-blocked below, that's a different, harder case with its own workaround. See also Error Messages A-Z.

A physician ended up as two separate accounts, and the NPI update is hard-blocked

Symptoms

• The same physician has two user accounts: one has the correct NPI but an incomplete or wrong login email, the other has the correct login email but no NPI
• Editing the second account to add the correct NPI fails immediately, with no confirmation dialog offered (unlike the simpler case above)
• Signed reports from this physician are stuck and never reach the EMR, since a report can't transmit without the physician's NPI, and this can also block billing

Where to look: the account you're editing shows the update rejected outright, not a "profile already exists, add it to your org?" prompt. If you get that prompt instead, use the simpler fix above, this section doesn't apply to you.

Likely cause

The two accounts most often come from the same physician being onboarded twice through different paths (for example, an automated FHIR/HL7 sync creating one account, and manual onboarding creating another) with no matching login email or NPI to link them. OmegaAI enforces NPI uniqueness system-wide, correctly, as a data-integrity constraint, but it can't tell you these two records are the same person, and neither account is aware the other exists.

What to try (the NPI swap workaround)

Note: this is a manual workaround, not a permanent fix

There's currently no self-service tool for merging two already-existing accounts into one. A proper user-merge feature is on the roadmap but not yet available, with no committed timeline. Until it ships, resolving this requires manually moving the NPI to the correct account and retiring the other one, as described below.

The steps:

1. Identify both accounts - Account A has the correct NPI but the wrong/incomplete email; Account B has the correct email but no NPI.

2. Free up the NPI on Account A: first try simply clearing the NPI field and saving, then re-open the account to check whether it stayed empty. Depending on your organization's rollout, OmegaAI may silently restore the old value on save (a newer data-protection behavior that stops key identifier fields being emptied by mistake). If the field stayed empty, skip the placeholder and go straight to step 3. If the value came back, the field can only be overwritten: replace it with a placeholder that could never be mistaken for this physician's real NPI. The field accepts letters as well as digits, so a short word-based value (kept under about 16 characters) reads unmistakably as a placeholder to the next person who opens the record. Do not just alter a digit or two of the real NPI, a near-miss value looks legitimate to downstream systems and to anyone reading it later. Agree the placeholder format with your administrator, keep it consistent, and write down which account carries which placeholder.

   Note that deactivating Account A later will not release the NPI - only replacing the value does. That's why this step comes first rather than last.

   Warning: Account A stays live until you deactivate it

   Between this step and step 6, Account A is still active with its NPI cleared or replaced by a placeholder. Anything signed under it in that window goes out with missing or bad identifier data on billing and HL7 paths. Work through the remaining steps in one sitting where you can, and don't leave an account parked in this state.

3. Add the real NPI to Account B now that it's no longer in use elsewhere.

4. Before deactivating Account A, find every reference to it - studies or reports signed under it, any workflow automation rules pointing to it, and any external system or interface tied to it - and update what you can to point to Account B.

   Warning: do not lose the audit trail

   Deactivating Account A does not delete its history. Reports and studies it already signed must keep their original record for audit and compliance purposes, don't try to rewrite history to Account B, just make sure future activity uses the right account.

5. Notify stakeholders and get approval before deactivating: the operations team managing the organization, the physician if they log in directly, anyone relying on Account A in an external system, and your manager or compliance team, since this change touches the audit trail. Get sign-off before the next step.

6. Deactivate Account A. Leaving it active risks a report being signed under the wrong account again.

   Exception: don't deactivate an account another organization actively uses

   Not every split is a mistake. If Account A is a working account for a different organization - for example one created and kept in sync from another RamSoft system such as PowerServer - leave it active and stop after steps 2-4: free the NPI, add it to the account that signs reports, and check references. The other organization's system keeps its own copy of the identifier for its own billing, and it's fine if the two records no longer match.

7. Verify: sign a test report as Account B and confirm the outbound HL7 message carries the correct NPI and reaches the EMR.

Prevention: duplicate accounts are much easier to prevent than to fix, always search for the physician before creating a new account, and provide both a valid login email and the NPI at the same time during onboarding rather than planning to add one later. There's no built-in report that surfaces existing duplicates proactively, this is a "catch it at creation" problem.

Still stuck? Contact RamSoft Support if you can't locate the account holding the NPI, if the placeholder won't save, if deactivation errors out, if an external system reference can't be updated, or if reports still don't reach the EMR after Account B has the correct NPI. Don't work around a step that won't complete, an account left half-changed is worse than one you haven't started on. Provide the physician's name, the correct NPI, both account identifiers, and what you've already tried.