By Eric Andrew Kristof, RN, CAHIMS | Healthcare IT Professional | HIMSS Arkansas Chapter Member
About This Series: The HIMSS Word of the Day is a running blog series drawing from the HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025) — the authoritative reference for healthcare IT professionals and the primary study resource for CAHIMS and CPHIMS certification. Each post paraphrases the term in plain language, grounds it in real-world healthcare IT context, and adds a bedside nursing perspective you won’t find in a textbook.
📖 The Term: SAML (Security Assertion Markup Language)
Source: HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025)
🔍 Plain-Language Definition
Security Assertion Markup Language (SAML) is an XML-based standard for exchanging identity, authentication, and authorization information between security domains. The HIMSS Dictionary describes the exchange as taking place between an identity provider (IdP) and a service provider (SP). In everyday terms, the IdP is the system that knows who you are and checks your credentials, and the SP is the application you want to use. After the IdP authenticates a user, it sends the SP a signed message, called an assertion, that vouches for the user.
An assertion can contain three kinds of statements: that the user was authenticated and how and when, attributes about the user such as role or department, and authorization decisions about whether the user may access a resource. Because the SP trusts the IdP, the user does not need a separate password for each application.
| SAML Concept | What It Is | Plain-Language Picture |
|---|---|---|
| Identity Provider (IdP) | System that authenticates the user | The hospital’s central login service |
| Service Provider (SP) | Application that relies on the IdP | A learning platform or vendor portal |
| Assertion | Signed statement about the user | A note saying who the user is and what role they hold |
| Federation | Trust arrangement between organizations | Two organizations agreeing to accept each other’s logins |
| Single Sign-On (SSO) | One login for multiple applications | Logging in once for several tools |
⚠️ Exam Alert: SAML carries authentication and attribute information between an IdP and an SP, and it is commonly used for web single sign-on. SSO is the outcome, while SAML is one standard that can deliver it. OAuth is mainly about delegated authorization, and OpenID Connect adds an authentication layer on top of OAuth.
🌐 Why It Matters: Real-World Healthcare IT Context
Health care workers use many applications in a shift. Separate passwords for each one lead to forgotten credentials, help desk calls, sticky notes, and shared logins. SAML-based single sign-on lets the organization centralize authentication, apply strong controls such as multifactor authentication in one place, and cut off access in one step when someone leaves.
The basic flow is easy to describe. A user opens an application. The application, acting as the service provider, redirects the user to the identity provider. The IdP authenticates the user, perhaps with a password and a second factor, and then returns a signed SAML assertion to the application through the user’s browser. The application validates the signature, reads the statements, and grants a session. In an IdP-initiated flow the user starts from a portal tile instead, and the assertion is sent to the application without a prior request. SAML also defines a single logout profile and several ways to establish and terminate federated identities between organizations, including persistent and transient pseudonyms that limit what the service provider learns about the user.
Federation extends the idea across organizations. Federation allows a given credential service provider to supply authentication and, optionally, subscriber attributes to a number of separately administered relying parties, as NIST’s federation guideline in the SP 800-63 series describes, with a focus on identity federations and the assertions used to implement them. A health system might let employees reach a vendor’s portal using their hospital login, or let a partner clinic’s staff reach a shared application with credentials issued by their own organization. SAML is a common way to build those relationships, along with OpenID Connect.
The comparison with newer standards is useful. SAML uses XML and was designed for browser-based enterprise web applications. OpenID Connect uses JSON and is built on OAuth 2.0, which fits mobile and API-centered applications. In health IT, SMART on FHIR relies on OAuth 2.0 and OpenID Connect so that apps can launch from an EHR with context and authorized access to data. Organizations commonly run both families at once: SAML for older enterprise applications and OIDC for modern apps and APIs. Understanding which to expect avoids confusion during vendor onboarding.
The benefits are measurable. A study of workstation single sign-on and access management across eight health systems and 55 hospitals in the United Kingdom and Ireland measured actual login times before and after implementation and found an average clinician time saving of 316 hours per year freed from keyboard typing. The authors estimated the financial value of that time at about 54.1 million pounds per year across the participating hospitals. That study examined workstation SSO and access management, a broader category than SAML itself, but it illustrates why clinicians and executives care about reducing repeated logins.
Security considerations matter. A SAML deployment relies on correct configuration: signed assertions, validated signatures, limited assertion lifetimes, protected certificates and keys, and careful handling of attributes so that roles map to the right access. Misconfiguration can allow impersonation or privilege escalation. Strong authentication at the identity provider becomes the key control, since compromise of that one login can reach many applications, and logs at both the IdP and the SP are needed for investigations.
Common SAML-related problems:
- Expired or mismatched signing certificates breaking logins
- Role attributes mapped incorrectly, giving too much or too little access
- IdP outage that locks users out of every connected application
- Applications left outside SSO, keeping separate local passwords
- Slow deprovisioning from the IdP leaving stale accounts in applications
- Weak authentication at the IdP
What supports secure SAML-based SSO:
- Multifactor authentication at the identity provider
- Certificate inventory with renewal reminders
- Tested attribute-to-role mappings
- Break-glass access when the IdP is unavailable
- Prompt deprovisioning tied to HR events
- Logging and monitoring at both IdP and SP
🏥 The Nurse’s Perspective: Clinical, Bedside, & Workflow
Nurses rarely hear the word SAML, but they feel the difference between a login that works and one that does not.
At the Bedside
A fast, reliable single sign-on lets a nurse reach the EHR, the learning platform, and the scheduling tool without repeated passwords. Slow logins push staff toward workarounds such as leaving sessions open. Nurses help by reporting patterns, such as a particular workstation that always fails or an application that asks for a separate login.
When the identity service has a problem, many tools fail at once. Knowing the downtime phone number and procedure is part of readiness.
In Clinical Workflow
Role information flows from the identity provider to applications. If a float nurse has the wrong role mapped in a connected application, orders may fail or screens may be missing. Nurse managers help by submitting accurate role and unit changes quickly so access matches duties.
Nurse informaticists often join vendor onboarding for new clinical or educational applications. They ask whether the product supports the organization’s single sign-on, how roles will be set, and what happens during a login outage. They also help test with real nurse accounts across units.
In EHR Implementation (Go-Live Perspective)
During an Epic Go-Live, thousands of people need working logins at once. Teams test the identity connection ahead of time, create accounts and roles, and stage support for lockouts. At-the-elbow support analysts help users with first logins, multifactor enrollment, and password resets, and they log patterns of login failure so the identity team can respond quickly.
🎓 CAHIMS / CPHIMS & HIMSS Perspective
CAHIMS Exam Domain Mapping
SAML appears in security, identity, and standards questions:
| CAHIMS Domain | How SAML Appears |
|---|---|
| Healthcare & Technology Environments | Standards for identity exchange, federation between organizations |
| Clinical Informatics | Clinician workflow impact of single sign-on, role mapping |
| Healthcare Information & Systems Management | Identity providers, service providers, certificates, access control |
| Management & Leadership | Vendor requirements, risk management, access governance |
Key Terms to Know Alongside SAML
- Identity Provider (IdP) — system that authenticates users and issues assertions
- Service Provider (SP) — application that relies on assertions to grant access
- Assertion — signed statement about a user’s authentication, attributes, or authorization
- Federation — trust relationship that lets organizations accept one another’s identities
- OpenID Connect (OIDC) — authentication layer built on OAuth 2.0
- OAuth 2.0 — framework for delegated authorization
HIMSS Organizational Position
HIMSS supports healthcare cybersecurity and identity practices through its Healthcare Cybersecurity Community, education, and research. Members can find related resources through the HIMSS Resource Center.
🔗 Explore Further: External References
- OASIS — Security Assertion Markup Language (SAML) V2.0 Technical Overview https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html
- OASIS — Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
- NIST — SP 800-63C-4, Digital Identity Guidelines: Federation and Assertions https://csrc.nist.gov/pubs/sp/800/63/c/4/final
- HL7 — SMART App Launch https://hl7.org/fhir/smart-app-launch/
- OpenID Foundation — How OpenID Connect Works https://openid.net/developers/how-connect-works/
- Gellert et al. (2025), Advances in Health Information Science and Practice — Clinician Time Savings and Financial Value of Workstation Single Sign-On and Access Management in the United Kingdom and Ireland https://pubmed.ncbi.nlm.nih.gov/41333334/
Term source: HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025). All definitions in this series are paraphrased for editorial purposes. Readers are encouraged to consult the primary source for exact language.
Eric Andrew Kristof, RN, CAHIMS is a Healthcare IT professional and HIMSS Arkansas Chapter member based in Hot Springs Village, AR, with hands-on Epic Go-Live experience and a diverse healthcare and IT background. He writes at kristof.org at the intersection of clinical care and healthcare technology.
Leave a Reply