Healthcare Authentication

Priiism provides authentication patterns designed for healthcare organizations that need HIPAA-compliant access controls. This guide covers three scenarios: patient-facing apps, physician/staff apps, and the B2B2C model where hospital IT teams build clinical applications on Priiism.

Pattern 1: Patient-Facing App

Patient portals and consumer health apps need a balance of security and ease of use. Patients are non-technical users who expect a familiar login experience.

Recommended Configuration

Setting	Value	Reason
Auth method	Email/password	Universal, no corporate IdP dependency
Social login	Google (optional)	Convenience for patients; reduces password fatigue
MFA policy	Required	HIPAA requires reasonable safeguards for PHI access
MFA method	Email OTP or TOTP	Email OTP is easier for patients; TOTP is more secure
Session lifetime	72 hours	Balances security with convenience
Idle timeout	4-8 hours	Protects PHI on shared/forgotten devices

Setup Steps

Set up authentication on your project
Enable email/password (default) and optionally Google social login
Set MFA policy to Required
Enable Email OTP as the MFA method (most accessible for patients)
Set session lifetime to 72 hours
Set idle timeout to 4 hours (adjust based on your risk assessment)

Patient Identity Considerations

Email verification: Auth0 sends a verification email on signup. Consider requiring email verification before granting access to PHI.
Password reset: Patients frequently forget passwords. Ensure the password reset flow is clearly accessible on the login page.
Account lockout: Auth0 locks accounts after 10 failed login attempts by default. This protects against brute force attacks.
Audit trail: All authentication events (login, logout, password changes, MFA enrollment) are logged by Auth0 and available in the Priiism identity dashboard.

Pattern 2: Physician/Staff App

Clinical applications used by physicians, nurses, and administrative staff should use enterprise SSO through the hospital’s existing identity provider. Staff members already have credentials — don’t make them create another account.

Recommended Configuration

Setting	Value	Reason
Auth method	Enterprise SSO (SAML/OIDC)	Staff use their hospital credentials
Identity provider	Hospital AD / Okta	Federation with existing IdP
MFA policy	Required	HIPAA compliance for PHI access
MFA method	TOTP (authenticator app)	More secure than SMS; hospitals often already issue authenticator apps
Session lifetime	24 hours	One shift + buffer
Idle timeout	1-2 hours	Clinical workstations are often shared

Setup Steps

Have the hospital IT admin set up enterprise SSO for the organization
Connect the hospital’s Active Directory or Okta instance via SAML 2.0

Configure role mappings from hospital AD groups to Priiism org roles:

Hospital AD Group	Priiism Role	App Permissions
`Physicians`	Admin	Full read/write to patient records
`Nurses`	Member	Read/write within assigned departments
`Admin-Staff`	Member	Read access, scheduling, billing
`IT-Admins`	Owner	System configuration, user management
`Medical-Students`	Viewer	Read-only access for training

Set MFA to Required with TOTP as the method
Set idle timeout to 1 hour for workstations accessing PHI

Staff Identity Considerations

Shared workstations: Clinical environments often have shared computers. Short idle timeouts and mandatory re-authentication protect against unauthorized access.
Break-the-glass access: For emergency scenarios, consider a secondary admin account that can bypass normal access restrictions. Document and audit all emergency access.
Role-based access control: Map hospital departments and roles to Priiism roles. Use the most restrictive access that still allows staff to do their job.
Offboarding: When staff leave the hospital, disabling their AD account automatically revokes Priiism access (SSO federation handles this).

Pattern 3: B2B2C (Hospital IT Builds on Priiism)

The most powerful healthcare pattern: a hospital IT team uses Priiism as their development platform, building clinical applications that serve both staff and patients.

How It Works

Hospital IT Team (Org Admin)
    |
    +-- Connects hospital AD/Okta (Enterprise SSO)
    |
    +-- Approves project templates for clinical use
    |
    +-- Clinical developers build apps from templates
         |
         +-- Staff-facing apps -> Hospital SSO
         |
         +-- Patient-facing apps -> Consumer identity pool

Step-by-Step Setup

1. Hospital IT Gets a Priiism Organization

The hospital IT department creates a Priiism organization on an Enterprise plan. This org serves as the central management point for all clinical applications.

2. IT Admin Connects Enterprise SSO

Follow the Enterprise SSO guide to connect the hospital’s Active Directory or Okta. This allows IT staff and clinical developers to log into Priiism with their hospital credentials.

3. IT Admin Approves Project Templates

The IT admin reviews and approves project templates that meet clinical requirements:

HIPAA-compliant data handling
Required auth configuration (MFA, session timeouts)
Approved component libraries
Audit logging enabled

Templates ensure every clinical app starts from a secure, compliant baseline.

4. Clinical Developers Build Apps

Clinical developers (citizen devs, clinical informaticists, or IT staff) create projects from approved templates. They use the Priiism AI agent to describe what they need:

“Build a patient intake form that collects demographics, insurance info, and medical history. Store data in the project database with encryption.”

The AI agent generates the app from the approved template, inheriting all security and compliance settings.

5. Separate Auth Pools

Each app gets the right auth configuration for its audience:

Staff-facing apps use the hospital’s enterprise SSO. Physicians and nurses log in with their hospital credentials.
Patient-facing apps use a separate consumer identity pool. Patients create their own accounts with email/password + MFA.

This separation ensures:

Patient credentials are never stored in the hospital’s AD
Staff access is centrally managed by hospital IT
Each app has appropriate session and MFA policies for its user type

6. Inherited Security

All apps built on Priiism inherit platform-level security:

Encryption at rest: All data in project databases is encrypted. Sensitive fields (env vars, signing credentials) use AES-256-GCM.
Encryption in transit: All traffic uses HTTPS with TLS 1.3.
Audit trail: Authentication events, data access, and code changes are logged.
Sandboxed execution: Each project runs in an isolated container. No cross-project data access.
Secret management: API keys and credentials are encrypted and never exposed in code or logs.

HIPAA Compliance Checklist

Use this checklist when setting up authentication for healthcare applications:

Next Steps

Set Up Authentication — Enable Auth0 on your project
Enterprise SSO Setup — Connect your hospital’s IdP
Team Access & Permissions — Configure org and project roles