Identity, SSO, and Provider Directories

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

Identity is the layer every other part of a telemedicine platform trusts, which is exactly why it is dangerous to get wrong: a weak login is the most common way patient data leaks, and a stale provider directory is how an unlicensed or de-credentialed clinician ends up in a video visit. This article is for the founder, product manager, or hospital IT lead who needs to scope the identity layer honestly — what proofing the law expects, why providers will refuse to maintain yet another password, and what a "provider directory" actually is once you stop hand-waving. Get it right and identity disappears: patients log in once with confidence, clinicians use the badge they already have, and the schedule only ever offers a provider who is real, licensed, and currently allowed to practice. Get it wrong and you face the two worst failure modes in the same system — a breach of patient data and a clinician practicing where they should not. This is the deep dive behind the identity node on the telemedicine integration map.

The three identity questions

Before any protocol or vendor, get the shape of the problem. A telemedicine platform has to answer three distinct identity questions, and teams routinely build the first, half-build the second, and forget the third exists.

The first is patient identity: is the person booking this visit the actual human whose medical record you are about to open? The second is provider identity: is the person on the other end a real, currently licensed clinician — and is their login strong enough that no one can impersonate them? The third is the provider directory: independent of any single login, what is the platform's authoritative list of which providers exist, what they are licensed to do, and where? The first two are about proving a person in the moment; the third is about knowing your population of clinicians over time.

Hold the three apart, because they use different tools and fail in different ways. Patient and provider identity are governed by an identity standard (NIST SP 800-63) and delivered with proofing, authentication, and single sign-on. The directory is a data problem solved with healthcare data standards (FHIR) and a credentialing process. The rest of this article walks them in that order.

Figure 1. The identity layer. Patient identity and provider identity prove a person in the moment; the provider directory is the platform's standing list of who may practice. Everything else — scheduling, the visit, prescribing, billing — trusts this layer.

Patient identity: proofing and the NIST levels

Start with the patient, because here the question is not "what is their password" but "how sure are we this is the right person at all." Linking a login to the wrong medical record is one of the most dangerous mistakes a health system can make — it can put one patient's history in front of another, and it is the root of countless billing and safety errors.

The U.S. reference for how rigorously you check identity is NIST Special Publication 800-63, the federal Digital Identity Guidelines, whose fourth revision was finalized in July 2025 [1]. It separates two ideas that beginners blur together. The first is identity proofing — how confident you are that a person is who they claim when you first enroll them — graded as an Identity Assurance Level (IAL) [2]. The second is authentication — how strong their login is every time they return — graded separately as an Authenticator Assurance Level, which we cover in the next section.

The proofing levels are a ladder:

• IAL1 — no verification. The user asserts a name and email; you take their word for it.
• IAL2 — moderate verification. You check reliable evidence (a government ID, a verified phone number, a knowledge check), either remotely or in person.
• IAL3 — the highest bar. Identity is verified with physical presence and supervised document checks, reserved for high-risk cases [2].

The practical question is which level a telemedicine product needs, and the honest answer is it depends on what the visit can do. A wellness app that hands out general information can live at IAL1. The moment a visit can lead to a prescription, a diagnosis in the legal record, or a paid insurance claim, you are at IAL2 — you need real evidence that the patient is who they say. And one specific feature forces the issue: prescribing controlled substances electronically (EPCS) requires identity proofing of the prescriber to a federal standard, which we cover in e-Prescribing and EPCS. Proofing is not a single setting for the whole app; it scales with what the riskiest action behind that identity can do.

A related job hides inside patient identity: patient matching — connecting the person who just proved their identity to the correct existing record in the electronic health record (EHR), the clinical system of record. Two patients named Maria Garcia with birthdays a week apart are a real and routine problem. Proofing tells you the person is genuine; matching tells you which chart is theirs. Treat them as two steps, because a confidently proven identity attached to the wrong chart is worse than no identity at all.

Authentication: AAL, and why MFA is becoming mandatory

Proofing happens once at enrollment. Authentication happens every single login, and its job is narrower: prove the returning user is the same person you proofed. NIST grades login strength as the Authenticator Assurance Level (AAL) [3]:

• AAL1 — single factor. A password alone. Acceptable only for low-risk access.
• AAL2 — multi-factor authentication (MFA): something you know plus something you have or are, such as a password plus a one-time code or a phone prompt [3].
• AAL3 — hardware-based, phishing-resistant authenticators such as a security key or smart card, resistant to impersonation [3].

For years, HIPAA's Security Rule did not name MFA. It required "a procedure to verify that a person seeking access is the one claimed" under 45 CFR § 164.312(d), and treated stronger controls as "addressable" — implement them or document why you reasonably did not. That era is ending. The HHS Office for Civil Rights issued a Notice of Proposed Rulemaking on January 6, 2025 (RIN 0945-AA22) to modernize the Security Rule, and two of its proposals reshape identity directly: it would make multi-factor authentication mandatory for access to electronic protected health information, and it would remove the "addressable" category entirely, turning previously-optional safeguards into firm requirements [4].

A precise word on status, because dates matter in compliance writing. This is a proposed rule. Its public comment period ran into March 2025, and as of this writing in June 2026 no final rule has been published, so the firm MFA mandate is not yet binding law [4]. But the direction is unambiguous, the major identity providers already default to MFA, and building single-factor login today is building rework. Treat AAL2 as the floor for any access to patient data, and reserve AAL3 (hardware keys) for your highest-privilege accounts — the administrators who can see every patient. The exact rollout and any final-rule deadline should get a counsel review before you rely on them.

Here is the most common authentication mistake, and it is a quiet one: putting patient data inside the login token. When a user signs in, the system issues a token (often a JSON Web Token, or JWT) that travels with each request. Teams sometimes stuff convenient fields into it — a patient name, a diagnosis, a medical record number. That token is base64-encoded, not encrypted; anyone who captures it can read every claim inside. A JWT carrying "diagnosis: depression" is protected health information (PHI) — any health data tied to an identifiable person — sitting in plain view in browser storage and server logs. Keep tokens to opaque identifiers and authorization scopes; never let them carry clinical detail.

Figure 2. The NIST assurance grid. Identity proofing (IAL, how hard you checked who they are) runs one way; authentication (AAL, how strong the login is) runs the other. Most clinical telemedicine lives at IAL2 / AAL2; controlled-substance prescribing and admin access push higher.

Provider sign-on: nobody wants another password

Now flip to the clinician, where the rule is human before it is technical: a doctor will not maintain a separate password for your platform. A hospitalist may touch a dozen systems in a shift. Each extra credential is a sticky note on a monitor and a help-desk ticket waiting to happen. The expectation, especially for any platform sold to hospitals, is that providers sign in with the identity they already have.

The mechanism is single sign-on (SSO) — the user authenticates once with a central identity provider (IdP), the system the organization already trusts to hold employee logins, and that IdP vouches for them to every connected application. Your platform becomes a service provider that trusts the hospital's IdP instead of running its own password database. Two standards carry that trust, and you will support both:

• SAML 2.0 (Security Assertion Markup Language) — the older, XML-based standard, still dominant in hospital and enterprise SSO. The IdP sends your app a signed XML "assertion" that says who the user is.
• OpenID Connect (OIDC) — the modern standard, built on OAuth 2.0, used by newer IdPs and almost every consumer login. The IdP returns a signed token (an id_token) describing the user [5].

Inside an EHR, there is a healthcare-specific flavor of this. When your app launches from within Epic or Oracle Health, it uses SMART on FHIR — the SMART App Launch framework, which layers OAuth 2.0 and OpenID Connect with healthcare scopes and clinical context [5]. In an EHR launch, the clinician is already signed into the EHR; the EHR opens your app with a context handle, and your app exchanges it for an access token and the openid/fhirUser scopes that identify the logged-in clinician — no second login, and the patient already in context [5]. This is the same SMART framework described in HL7 v2, FHIR, and the EHR integration reality, applied to identity instead of clinical data.

SSO has a twin that teams forget until it bites them: provisioning and deprovisioning — creating and, crucially, removing accounts. When a clinician joins, an account appears; when they leave or lose privileges, it must vanish everywhere, fast. The standard that automates this is SCIM (System for Cross-domain Identity Management), a protocol that lets the IdP push "create user," "update user," and "deactivate user" events to your platform [6]. Without it, offboarding is a manual checklist, and manual checklists miss systems. A former clinician whose account still works is a textbook audit finding and a real breach risk.

That risk is worth a number, because it is invisible until you look. Suppose a 200-provider platform has a typical clinician turnover of 15% a year, and each offboarding is handled by a manual ticket that, on a busy week, takes three days to fully close:

200 providers × 15% turnover = 30 departures/year
30 departures × 3 days each = 90 provider-days/year
  of still-active accounts that should be dead

Ninety provider-days a year of live credentials for people who have left — each one able to open patient charts — is the gap automated SCIM deprovisioning closes to near zero. The "encrypted, MFA-protected" login means nothing if it still belongs to someone who walked out the door. The fix is to let the IdP, not a human, switch accounts off the moment HR does.

Figure 4. Provider sign-on. The clinician authenticates once at the hospital identity provider over SAML or OpenID Connect; inside an EHR the app launches via SMART on FHIR with the openid/fhirUser scopes; SCIM provisions accounts on join and deactivates them on departure.

The provider directory: the platform's source of truth

The third identity question is the one nobody demos and everybody needs. Separate from any login, your platform must hold an authoritative answer to: which clinicians exist, what is each one licensed and credentialed to do, and where? That is the provider directory — the standing list the rest of the system trusts.

Every clinician in the United States has a National Provider Identifier (NPI) — a unique 10-digit number issued by the federal NPPES registry (the National Plan and Provider Enumeration System), which publishes a public file of more than seven million provider records [7]. The NPI is the stable anchor you key a provider to, the way a product is keyed to a SKU. But note the trap up front: an NPI proves a number was issued; it does not prove the person is currently licensed, in good standing, or even alive. The NPI is an identifier, not a credential.

Turning that identifier into a trustworthy directory entry takes credential verification — confirming a clinician's licenses, education, and standing directly with the issuing source, a process called primary source verification (PSV) [8]. You do not take the provider's word, or a photocopy; you check the state medical board, the school, the certifying body. Health plans and hospitals run this through a Credentials Verification Organization (CVO) against standards set by the National Committee for Quality Assurance (NCQA), and most clinicians keep their data in CAQH ProView, a shared profile that payers pull for verification [8]. NCQA's 2025 standards tightened the cadence, requiring monthly monitoring of license status and exclusion lists rather than a check only at hiring [8]. For a telemedicine build, the lesson is that credentialing is not a one-time import; it is a feed your directory must keep ingesting.

For the data shape, healthcare has a standard so you do not invent your own. FHIR models a clinician as a Practitioner resource and — the important one — a PractitionerRole, which ties a practitioner to an organization, a location, the services they provide, and the networks they belong to [9]. The industry profile for an interoperable directory is the Da Vinci PDEX Plan-Net implementation guide, which standardizes how a directory of in-network providers is published over FHIR, building on the US Core Practitioner, Organization, and Location resources [9]. If you model your directory on PractitionerRole and Plan-Net from the start, it can both consume external directories and expose its own without a rewrite.

There is also a legal reason to keep the directory fresh, not just a clinical one. Under the federal No Surprises Act, health plans must verify the accuracy of their provider directory information at least every 90 days and update it within a short window when a provider submits a change [10]. Directory data decays faster than teams expect, which makes that rule bite. Walk the arithmetic:

Provider data decays at ~2.5%/month (address, status, network changes)
12 months × 2.5% = ~30% of entries drift in a year
A directory verified only at onboarding is ~30% wrong by next year

Roughly a third of an unmaintained directory is stale within a year — wrong locations, lapsed licenses, providers who left. That is why the directory is a living feed wired to NPPES, the CVO, and the credentialing process, not a spreadsheet imported once. And it closes the loop with scheduling: the cross-state licensing check that Scheduling and Calendar Integration insists must run before a slot is offered is only as good as the directory feeding it. A clinician must generally be licensed in the state where the patient is physically located at visit time; the directory is where that fact lives.

Figure 3. The provider directory as source of truth. NPI anchors each clinician; primary-source verification and monthly monitoring keep licenses current; FHIR PractitionerRole / Plan-Net is the data shape. The directory then gates scheduling, SSO, and prescribing.

Choosing the identity layer: build, or buy with a BAA

You rarely build authentication from scratch — getting MFA, session handling, and SSO federation right is a specialty, and a rolled-your-own login is where breaches start. The realistic choice is which identity platform to stand on, and the healthcare-specific gate is the same one that governs every vendor in this section: a Business Associate Agreement (BAA) — the contract that makes it lawful for an outside vendor to handle patient data on your behalf. If user records or tokens can touch PHI, the identity vendor needs a signed BAA, full stop. "Encrypted" is not "compliant"; the contract is what makes the difference.

Vendor BAA terms and plan eligibility change; the "BAA available?" column reflects general availability and must be re-verified against each vendor's current healthcare terms before you sign. Self-hosting Keycloak removes the vendor BAA question and replaces it with your own responsibility for every control.

Two honest trade-offs sit in that table. A hosted identity-as-a-service (IDaaS) vendor gives you MFA, SSO, and audit logging on day one but puts identity data — potentially PHI-adjacent — on their infrastructure, so the BAA and their configuration are load-bearing. Self-hosting Keycloak keeps everything inside your boundary and removes the third-party BAA question, but now you own patching, availability, and every NIST control. Neither is wrong; the choice follows your team's depth and your compliance posture. The build-vs-buy logic mirrors the video layer decision in Choosing the video layer.

Authentication is not authorization

One conceptual mistake causes more security bugs than any protocol error, so name it plainly. Authentication answers "who are you." Authorization answers "what are you allowed to see." SSO and SMART on FHIR solve the first; they do not solve the second. A clinician proving their identity through the hospital IdP does not mean they may open every patient's chart — they may see their patients, on their service, for a legitimate reason.

HIPAA requires this separation directly. The minimum-necessary principle and the access-management standard at 45 CFR § 164.308(a)(4) require that access be limited to what each role needs [11]. So even a perfectly authenticated, MFA-protected, SSO'd clinician must still pass an authorization check — role-based access, patient-relationship checks, and the audit logging that records who opened which chart, covered in Audit logging and access controls for clinical video. Build identity and access as two layers, not one. Conflating them is how an authenticated insider quietly browses records they had no business seeing.

Where Fora Soft fits in

Fora Soft has built real-time video and clinical software since 2005, and in telemedicine the identity layer is where two opposite risks meet: a login weak enough to breach, and a directory stale enough to put an unlicensed clinician in a visit. We design it compliance-first — multi-factor authentication as the floor for any access to patient data (ahead of the proposed 2026 HIPAA mandate), provider sign-on through the hospital's existing identity provider over SAML or OpenID Connect so clinicians never carry a second password, and SMART on FHIR launch where the platform lives inside an EHR. On the directory side we anchor each provider to their NPI, model the data on FHIR PractitionerRole and the Da Vinci Plan-Net profile, and wire it to the credentialing feed so the licensing check runs on current facts — keeping authentication and authorization as two distinct layers, because proving who someone is never settles what they are allowed to see.

What to read next

• Who is in the room: roles, identity, and consent
• HL7 v2, FHIR, and the EHR integration reality
• Scheduling and Calendar Integration

Download the Telemedicine Identity & Access Checklist (PDF)

Call to action

• Talk to a telemedicine engineer — book a 30-minute scoping call to talk through your telemedicine identity and access management plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Telemedicine Identity & Access Checklist — One page to scope the identity layer of a telemedicine product: patient identity proofing (NIST IAL), authentication strength and the proposed 2026 MFA mandate (NIST AAL), provider SSO via the hospital IdP and SMART on FHIR, SCIM….

References

1. NIST Special Publication 800-63, Revision 4 — Digital Identity Guidelines — National Institute of Standards and Technology. The federal Digital Identity Guidelines; Revision 4 finalized July 2025. Defines the identity assurance framework (IAL, AAL, FAL) and the risk-based Digital Identity Risk Management approach. The controlling U.S. reference for proofing and authentication strength. Tier 1. https://pages.nist.gov/800-63-4/sp800-63.html
2. NIST SP 800-63A-4 — Identity Proofing and Enrollment — NIST. Defines Identity Assurance Levels IAL1 (no proofing), IAL2 (moderate, remote or in-person evidence), and IAL3 (high, with physical presence and supervised verification). The proofing ladder. Tier 1. https://pages.nist.gov/800-63-4/sp800-63a.html
3. NIST SP 800-63B-4 — Authentication and Authenticator Management — NIST. Defines Authenticator Assurance Levels: AAL1 (single factor), AAL2 (multi-factor authentication), AAL3 (hardware-based, phishing-resistant). The login-strength ladder. Tier 1. https://pages.nist.gov/800-63-4/sp800-63b.html
4. HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information — NPRM (RIN 0945-AA22) — HHS Office for Civil Rights, Federal Register, January 6, 2025. Proposes mandatory MFA for ePHI access, removes the "addressable" implementation specification category, and modernizes 45 CFR Part 164 technical safeguards. Proposed rule — comment period closed March 2025; no final rule published as of June 2026; re-verify status before relying on the mandate. Tier 1. https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information
5. SMART App Launch Framework, v2.2.0 — HL7 / SMART Health IT. Builds on OAuth 2.0 and OpenID Connect with healthcare scopes and clinical launch context; defines EHR launch and standalone launch, and the openid / fhirUser scopes that identify the signed-in user. The standard for app sign-on inside an EHR. Tier 3 (standards-author specification). https://hl7.org/fhir/smart-app-launch/
6. System for Cross-domain Identity Management (SCIM 2.0) — RFC 7644 — IETF. The protocol for automated user provisioning and deprovisioning between an identity provider and a service provider (create / update / deactivate user). The basis for instant offboarding. Tier 1 (IETF standard). https://datatracker.ietf.org/doc/html/rfc7644
7. NPPES — National Plan and Provider Enumeration System / National Provider Identifier (NPI) — CMS. Issues the unique 10-digit NPI to U.S. providers and publishes the public NPI registry file (7M+ records). The stable anchor for a provider directory; an identifier, not a credential. Tier 1. https://nppes.cms.hhs.gov/
8. Credentialing Standards & Primary Source Verification — National Committee for Quality Assurance (NCQA) and CAQH. NCQA defines primary-source verification of licenses, education, and standing through a CVO; 2025 standards add monthly monitoring of license status and exclusion lists; CAQH ProView is the shared provider-data profile payers verify against. Tier 5 (accreditation body / industry utility; underlying licenses are issued by state boards). https://www.ncqa.org/programs/health-plans/credentialing/
9. Da Vinci PDEX Plan-Net, v1.2.0, and FHIR R4 PractitionerRole — HL7 International. The FHIR implementation guide for an interoperable provider directory, building on US Core Practitioner / Organization / Location plus R4 PractitionerRole, HealthcareService, and Endpoint. The data shape for a directory. Tier 3 (standards-author specification). https://hl7.org/fhir/us/davinci-pdex-plan-net/
10. No Surprises Act — Provider Directory Accuracy (Public Health Service Act § 2799A-5) — U.S. Congress / CMS. Requires plans to verify provider directory information at least every 90 days and update promptly on provider-submitted changes. The federal driver behind keeping a directory current. Tier 1 (statute). https://www.cms.gov/nosurprises
11. 45 CFR § 164.308(a)(4) (Information Access Management) and § 164.312(d) (Person or Entity Authentication) — HHS / Code of Federal Regulations. The Security Rule standards requiring access limited to the minimum necessary by role, and a procedure to verify a person seeking access is the one claimed. The authentication-vs-authorization separation in law. Tier 1. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312

Per the source hierarchy, the proofing/authentication framework is cited to NIST SP 800-63-4 (refs 1–3, tier 1); the MFA mandate and access standards to the HHS NPRM and the CFR (refs 4, 11, tier 1); the NPI anchor and directory-accuracy rule to CMS/NPPES and the No Surprises Act statute (refs 7, 10, tier 1); the app-launch and directory data shapes to the SMART and Da Vinci FHIR specifications (refs 5, 9, tier 3) and SCIM to the IETF RFC (ref 6, tier 1); and the credentialing process to NCQA/CAQH (ref 8, tier 5, with state boards as the underlying primary source). Of 11 sources, 8 are tier-1 primary regulatory/standards documents (73%); every compliance claim — the proofing levels, the proposed MFA mandate, the authentication standard, the directory-accuracy rule, and the minimum-necessary access limit — traces to a primary regulatory or standards source.