A growing imaging group eventually hits a wall that has nothing to do with scanners, storage, or read volume. It is a smaller problem that becomes a bigger one the moment a second site opens: who gets access to which studies, who can see which referring contacts, and who is responsible for updating any of it once a role changes. Today, PACS user management for a multi-site OmniPACS customer runs through a support request. An administrator describes the change and waits for someone else to make it.
That gap, between how fast an imaging organization grows and how slowly its access model keeps up, is the one enterprise user management is built toward closing.
When PACS User Management Means Emailing the Vendor
For a single radiology practice, this arrangement barely registers as friction. One office, one login list, one point of contact. Multiply that by a regional group with a half dozen sites, rotating per-diem staff, and a referral network that shifts every quarter, and the same arrangement becomes a queue.
A new tech cannot start reading until someone remembers to request access. A departing employee keeps a valid login until someone remembers to request its removal.
Today, that adjustment happens through support@omnipacs.com, the same channel that handles routine help requests. It works, in the sense that the request eventually gets done. It is also the wrong tool for something a site administrator should not need a ticket to do at all, and that kind of request is exactly what grows fastest as an imaging organization adds sites.
What Stale Accounts and Shared Logins Actually Risk
The operational cost of a slow access process is annoying. The compliance cost is the part that should worry a multi-site administrator more. An account that outlives the person who used it, sometimes called a stale or orphaned account, is not a hypothetical. It is one of the more common findings in healthcare access reviews: a former employee, contractor, or per-diem tech whose login was never revoked, sitting active in a system long after anyone remembers why.
Shared logins carry a related but distinct risk. When several staff members use one credential to save time during a busy shift, the system can no longer answer a basic question: who actually looked at this study, and when. That gap matters clinically, and it matters legally.
What HIPAA and NIST Actually Require
The HIPAA Security Rule does not leave this to informal judgment. Its administrative safeguards for workforce security and information access management require a covered entity to control who is authorized to access electronic protected health information, and to have a defined procedure for removing that access when someone’s role changes or ends. The implementation guidance built around those same safeguards is just as direct: authorize access, establish and modify it as responsibilities change, and terminate it, rather than leaving it as a step nobody explicitly owns.
A compliance officer already working through the administrative and technical safeguards a HIPAA compliance checklist puts in front of every imaging environment does not need any of that re-explained. What is usually missing is not the policy, it is the mechanism: a way for the person who already knows a role changed to act on it immediately, instead of routing the update through a request queue and hoping it lands before the next access control and role review catches what daily process did not.
The Direction of Travel: Provisioning and De-Provisioning an Administrator Can Own
This is the specific gap enterprise user management is built toward closing. The direction OmniPACS is heading is straightforward to describe even before every detail of it exists: a site administrator should be able to grant a new hire access the day they start, adjust an existing account when a role changes, and remove access the moment someone leaves, without a request sitting behind someone else’s ticket.
Provisioning and de-provisioning are two sides of the same problem, and the second one is the half that tends to get neglected. Granting access gets attention because someone is waiting to start work. Removing it does not carry the same built-in urgency, which is exactly how stale accounts accumulate in the first place. The direction this is heading treats both as equally routine: healthcare user provisioning and its reverse are meant to become one action, owned by one person, on one timeline, not two separate requests with two different response times.
What that does not mean, at least not yet, is a specific set of screens, roles, or settings. OmniPACS has not shipped this capability, and describing it more precisely than direction of travel would be getting ahead of what is actually built. What can be said is the problem it answers: an administrator should not need a vendor’s help desk to remove a departed employee’s access on the day they leave.
Role-Based Access for Imaging Contacts and Sharing Relationships
Access is not only about who can log in. It is also about which contacts, referring providers, specialists, partner facilities, appear as sharing destinations for a given user, and which relationships a given role should even be able to see. A front-desk scheduler and a reading radiologist do not need the same view of a group’s referral network, and today that distinction is either handled informally or not handled at all.
The same direction of travel that governs provisioning extends to this layer: role-based access for imaging staff, scoped to contacts and sharing relationships, so that what a user can see and share lines up with what the job actually requires, instead of defaulting to everyone seeing everything because separating it was never worth the setup effort. That is a smaller-sounding problem than provisioning, but it is the one that shows up in a compliance review as a minimum-necessary-access finding, not a headline-making breach.
Where Corporate IT Fits: Federated Identity and Single Sign-On
Multi-site groups large enough to run a dedicated IT function want something PACS-level administration cannot fully provide on its own: centralized control over the account lifecycle itself, not just the roles inside one platform. That is where the roadmap points next. Federated identity and single sign-on would let a corporate IT team keep account creation, multi-factor authentication, and audit logging centralized in the identity system it already runs for the rest of the organization, with OmniPACS Condor recognizing that identity rather than maintaining a fully separate login of its own.
That is a meaningfully different kind of control than site-level user management, and it is the piece that turns a PACS evaluation into an enterprise IT conversation instead of a departmental one. It is also, honestly, further out than the provisioning and role-based work described above. Nothing here carries a date, and nothing about how it will actually work is locked down enough to describe beyond the direction itself: corporate IT should not have to trust a second identity system it does not control.
What This Means for Multi-Site Groups and Compliance Officers
An OmniPACS site’s day-to-day work is not what changes here. What changes is who has to be involved to keep doing it as an organization adds sites. A single-site practice can keep routing access changes through a support request indefinitely and rarely notice the cost. A multi-site group, an IT decision-maker evaluating a PACS platform for a larger health system, or a compliance officer who has to answer for an outdated access list, is the audience this work is actually for.
That audience is also the one asking a fair question before any of this ships: what changes in the meantime? The honest answer is that OmniPACS Condor’s rebuilt foundation, a modern API-first backend supporting a React front end rather than the legacy PHP application it replaced, is what makes enterprise-level administration buildable at all. A decade-old, tightly coupled codebase does not accommodate a new administrative surface without months of careful surgery.
A modern, services-based architecture does. That is not a claim about a feature that exists yet. It is a claim about why the platform is positioned to build this kind of capability on a timeline the old one could not have supported.
Sizing Up What a Rollout Actually Changes
None of what is described here is available today, and framing it otherwise would misrepresent where OmniPACS actually is on this roadmap. What is true today is the direction: PACS user management is moving toward site administrators, provisioning and de-provisioning are meant to become one routine action instead of two, and the eventual reach toward federated identity is aimed squarely at the IT teams and compliance officers who have the most reason to care exactly how access is controlled.
For multi-site groups deciding whether now is the right time to move onto Condor, or working out what changes once they do, the more useful conversation is not with a features page. Talk to us about your site’s rollout and what a multi-site access model would actually need to look like on the platform as it exists today, since that answer depends on specifics a roadmap description cannot cover. The scale of that conversation is different from a single-site question, and it should be: an organization sizing up enterprise user management is usually sizing up what OmniPACS can support across every site it runs, not just the one asking first.
Frequently Asked Questions
Is sharing passwords a HIPAA violation?
Sharing a login credential is not named as a specific violation in HIPAA’s text, but it undermines the access controls and audit-trail requirements the Security Rule does require, and it is a common finding in risk assessments and OCR investigations. Most compliance programs treat it as a policy violation on its own.
What is user provisioning and de-provisioning?
User provisioning is creating and configuring someone’s access to a system, typically when they are hired or change roles. De-provisioning is the reverse: removing that access when someone leaves or no longer needs it. In healthcare specifically, both matter because an account left active past its need becomes a stale-account risk.
What is single sign-on (SSO) in healthcare IT?
Single sign-on lets a user authenticate once, through a central identity provider, and reach multiple connected systems without a separate login for each one. In healthcare IT, SSO usually sits with corporate IT rather than an individual application, since it centralizes account creation, multi-factor authentication, and audit logging across every system an organization runs.
What is the minimum necessary rule for PHI under HIPAA?
The minimum necessary rule requires covered entities to limit access, use, and disclosure of protected health information to the smallest amount needed for a given purpose. For PACS access specifically, that means a user’s role, not convenience or default settings, should determine which studies, contacts, and sharing relationships they can actually see.