Healthcare Module

Healthcare identity.
SMART on FHIR. HIPAA-ready.

Building a healthcare app? Activate the healthcare module per tenant. Get SMART on FHIR scopes, EHR launch context, fhirUser claims, HIPAA-grade audit logging, and integration with Epic, Cerner, and any FHIR R4 server.

Healthcare auth is hard

Healthcare apps don't just need login. They need EHR integration, HIPAA compliance, patient consent flows, and clinical scopes. Building this from scratch takes months. AuthFI handles all of it.

H

EHR integration

Your app needs to launch from Epic, Cerner, or any EHR. That requires SMART on FHIR — a complex OAuth2 extension with clinical scopes and launch context.

S

HIPAA compliance

Every access to patient data must be logged. Encryption required at rest and in transit. Access controls must be role-based. You need a BAA with your auth provider.

C

Patient consent

Patients control who sees their data. Consent must be captured during authorization and enforced on every request. Scopes define the boundary.

R

Clinical scopes

Standard FHIR scopes like patient/*.read and launch/patient. Not custom permissions — standard scopes that every EHR system understands.

AuthFI handles all four. Activate the healthcare module per tenant. Your app gets SMART on FHIR, HIPAA compliance, consent flows, and clinical scopes — with zero custom auth code.

SMART on FHIR scopes

Standard clinical scopes from the SMART App Launch Framework v2.2.0. Your app requests scopes during authorization. The patient consents. AuthFI enforces.

ScopeDescriptionCategory
patient/*.readRead any FHIR resource for the patient in context. Lab results, medications, conditions, allergies.Patient
patient/*.writeWrite FHIR resources for the patient. Clinical notes, orders, care plans.Patient
patient/Observation.readRead only Observation resources (vital signs, lab results). Narrow scope for monitoring apps.Patient
patient/MedicationRequest.writeWrite medication orders. Requires doctor role and MFA verification.Patient
launch/patientApp receives patient context during EHR launch. The patient ID is in the token.Launch
launch/encounterApp receives encounter context. Knows which visit/appointment the clinician is in.Launch
user/*.readRead resources accessible to the logged-in user (clinician). Not patient-scoped — user-scoped.User
openid fhirUserReturns the FHIR resource reference for the user. Practitioner/123 or Patient/456.Identity

1. App requests scopes

scope=openid
      fhirUser
      launch/patient
      patient/*.read

// Requested during /authorize

2. Patient consents

Consent screen:

"Lab Results App" wants to:

● View your medical records
● Know your patient ID
● Know your care provider

[Allow]  [Deny]

3. Access granted

✓ Token issued with scopes:

  openid
  fhirUser
  launch/patient
  patient/*.read

// Enforced on every FHIR request

FHIR user references

Every AuthFI user can have a FHIR resource reference. The fhirUser claim in the token tells the EHR system exactly who this person is in FHIR terms.

Practitioners (clinicians)

AuthFI User → FHIR Reference

dr.smith@hospital.com
  fhirUser: Practitioner/123
  roles: [doctor]
  NPI: 1234567890

nurse.jones@hospital.com
  fhirUser: Practitioner/456
  roles: [nurse]
  NPI: 0987654321

Patients

AuthFI User → FHIR Reference

john.doe@email.com
  fhirUser: Patient/789
  roles: [patient]
  MRN: 12345

jane.doe@email.com
  fhirUser: Patient/790
  roles: [patient]
  MRN: 12346
How auth token carries FHIR context: { "sub": "usr_drsmith", "email": "dr.smith@hospital.com", "roles": ["doctor"], "fhirUser": "Practitioner/123", ← who the clinician is in FHIR "patient": "Patient/456", ← which patient they're accessing "encounter": "Encounter/789", ← which visit/appointment "scope": "openid fhirUser launch/patient patient/*.read", "iss": "https://hospital.authfi.app" } // The FHIR server uses these claims to scope data access. // Patient/456's data only. No cross-patient access.

HIPAA compliance checklist

AuthFI provides the technical safeguards required for HIPAA compliance. Every item is built in — not a bolt-on or upgrade.

RequirementHow AuthFI delivers
✓Encryption at rest (AES-256)All data encrypted at rest. Database, backups, logs.
✓Encryption in transit (TLS 1.3)All API calls over HTTPS. HSTS enforced. No plain HTTP.
✓Audit loggingEvery access decision logged: who, what, when, from where. Immutable audit trail.
✓Role-based access controlsRoles, permissions, groups, MFA enforcement. Granular and configurable.
✓Data residencyChoose deployment region. Data stays where you need it. US, EU, or custom.
✓BAA availableBusiness Associate Agreement available on Business and Enterprise plans.
✓Session managementConfigurable session timeouts. Force logout. Token revocation. SSO session control.
✓MFA enforcementRequire MFA for sensitive operations. TOTP, WebAuthn, SMS. Configurable per role/route.
✓PHI isolationTenant-level data isolation. No cross-tenant data access. Separate encryption keys per tenant.
✓Password policiesConfigurable complexity, rotation, history, lockout. Meets NIST 800-63B.
10/10
HIPAA technical safeguards
100%
access decisions audited
BAA
available on Business+ plans

Clinical workflow — end to end

Doctor logs in. SMART launch. Patient context established. EHR data accessed. Every step audit-logged. Here's the full flow.

1

Doctor logs into EHR

Clinician authenticates in the EHR system (Epic, Cerner). Opens a patient chart.

EHR System (Epic) Dr. Smith opens Patient: John Doe (MRN: 12345) → Encounter: Office Visit (ENC-789) → Launches "Lab Results" app from the EHR toolbar
2

SMART launch initiated

EHR redirects to AuthFI with launch context. AuthFI validates the launch and presents the consent screen.

GET /authorize? response_type=code &client_id=lab-results-app &scope=launch/patient patient/Observation.read openid fhirUser &launch=xyz789 &redirect_uri=https://labs.hospital.com/callback &aud=https://fhir.hospital.com/r4 ✓ Launch context resolved ✓ Patient: John Doe (Patient/456) ✓ Encounter: ENC-789
3

Patient context established

AuthFI resolves the launch context, maps the clinician to a FHIR user, and issues a token scoped to this patient.

Token issued: { "sub": "usr_drsmith", "email": "dr.smith@hospital.com", "fhirUser": "Practitioner/123", "patient": "Patient/456", "encounter": "Encounter/789", "scope": "launch/patient patient/Observation.read openid fhirUser", "iss": "https://hospital.authfi.app" }
4

App accesses FHIR resources

The app uses the token to query the FHIR server. Only resources for Patient/456 are accessible. Only Observation resources, per the scope.

GET /fhir/r4/Patient/456/Observation Authorization: Bearer eyJhbG... ✓ Token valid (RS256, not expired) ✓ Scope allows: patient/Observation.read ✓ Patient context: Patient/456 ✓ Returning 23 Observation resources // Lab results, vitals, etc. for John Doe only.
5

Every access audit-logged

AuthFI logs every token issuance, every scope grant, every FHIR access. Immutable. Queryable. HIPAA-ready.

Audit Log: TIME WHO ACTION RESOURCE 10:30:01 dr.smith SMART launch Patient/456 10:30:01 dr.smith scope granted patient/Observation.read 10:30:02 dr.smith token issued access_token (1hr) 10:30:03 lab-results-app FHIR read Observation (x23) 10:31:15 dr.smith session ended logout // Every action. Every resource. Every user. Exportable.

Works with every major EHR

AuthFI implements the SMART App Launch Framework. Any EHR system that supports SMART on FHIR R4 works out of the box.

EP

Epic

SMART on FHIR R4. MyChart integration. EHR launch and standalone launch.

Supported
CE

Cerner (Oracle Health)

SMART on FHIR R4. Millennium platform. Ignite APIs.

Supported
AL

Allscripts

SMART on FHIR R4. Open API platform. Sunrise and TouchWorks.

Supported
OP

OpenMRS

Open-source EHR. FHIR2 module. Custom SMART integration.

Supported
CU

Custom FHIR server

Any FHIR R4-compliant server. HAPI FHIR, Microsoft FHIR Server, Google Cloud Healthcare API.

Supported

Configure per tenant — one API call

POST /manage/v1/hospital/modules/activate { "module": "healthcare", "config": { "smart_version": "2.2.0", "ehr_systems": [ { "name": "Epic", "fhir_base_url": "https://fhir.hospital.com/r4", "client_id": "epic-app-id", "launch_type": "ehr-launch" } ], "default_scopes": ["openid", "fhirUser", "launch/patient"], "consent_screen": true, "audit_fhir_access": true } } ✓ Healthcare module activated ✓ SMART on FHIR scopes enabled ✓ .well-known/smart-configuration live ✓ EHR launch endpoint ready ✓ Consent screen configured ✓ FHIR access audit logging active

.well-known/smart-configuration

AuthFI auto-generates the SMART discovery endpoint. EHR systems use this to discover your app's authorization endpoints and supported capabilities.

GET https://hospital.authfi.app/.well-known/smart-configuration { "authorization_endpoint": "https://hospital.authfi.app/authorize", "token_endpoint": "https://hospital.authfi.app/oauth/token", "capabilities": [ "launch-ehr", "launch-standalone", "client-public", "client-confidential-symmetric", "sso-openid-connect", "context-ehr-patient", "context-ehr-encounter", "permission-patient", "permission-user" ], "scopes_supported": [ "openid", "fhirUser", "launch", "launch/patient", "launch/encounter", "patient/*.read", "patient/*.write", "user/*.read" ], "code_challenge_methods_supported": ["S256"] }

Auto-generated. Always up to date. EHR systems query this endpoint to discover your app's capabilities.

Related features

Authentication

The auth foundation that healthcare module extends

Enterprise SSO

Hospital IdPs connect via SAML for clinician authentication

Observability

HIPAA-grade audit logging for every patient data access

Available on Business and above. See pricing →

One platform. Every identity layer.
Free to start.

Free for 5,000 users. Upgrade when you're ready.

Start building free →

Startups and enterprises get 1 year free →