Single sign-on (SSO) lets clinicians and staff enter your product using their organization's existing identity rather than yet another username and password. Technically it is usually SAML or OIDC — protocols where your application trusts the hospital's identity provider (such as Azure AD, Okta, or the EHR's own login) to authenticate the user and assert who they are. The user signs in once to their organization and is admitted to your product without a separate credential.
In hospital sales, SSO is rarely optional. Security teams require it because centralized identity means central control: when an employee leaves, disabling one account removes access everywhere, and login policy (including MFA) is enforced in one place. Just as importantly, adoption measurably drops without it — every extra password is friction, and in a clinical workflow login friction is adoption friction.
The engineering implications are concrete. You map roles and permissions from the claims the identity provider sends, so a user's clinical role and access scope are driven by the hospital's directory rather than configured by hand in your app. You should also decide early that patient identity is a separate trust problem with its own approach — patients are not in the hospital's staff directory, and conflating the two is the common mistake. The right mental model, consistent with NIST SP 800-63 identity guidance, is that workforce SSO and patient identity verification are different problems solved with different mechanisms, and they should be designed as such from the start.
