Documentation Index
Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt
Use this file to discover all available pages before exploring further.
HIPAA Compliance Implementation Guide
This guide provides a complete reference implementation combining all concepts from previous modules into a production-ready healthcare application.- HIPAA-compliant FastAPI backend
- Encrypted database layer
- Audit logging system
- E2E encrypted chat with AI
- Complete access control
Project Architecture
Project Structure
Core Configuration
Environment Configuration
Main Application
Authentication & Authorization
Security Module
RBAC Implementation
Patient Records API
Patient Endpoints
Patient Service
E2E Encrypted Chat
Chat Endpoints
Chat Service
AI Integration
AI Endpoints
AI Service
Docker Deployment
Docker Compose
Dockerfile
Key Takeaways
Defense in Depth
Encrypt at Field Level
Audit Everything
AI Stays On-Premise
Next Steps
Compliance Checklist
Course Overview
Interview Deep-Dive
You are reviewing a pull request for a new patient API endpoint. What HIPAA-specific code review checklist items do you look for before approving?
You are reviewing a pull request for a new patient API endpoint. What HIPAA-specific code review checklist items do you look for before approving?
- Authentication and authorization: Does the endpoint require authentication (JWT validation)? Does it check RBAC permissions before returning data? Is the authorization check server-side (not relying on client-side role checks)? Does it verify the requesting user has a legitimate relationship to the requested patient (not just a valid token)?
- Data exposure: Does the API response include only the minimum necessary fields? A GET /patients/:id endpoint should return different field sets based on the caller’s role — a billing specialist gets billing fields, a clinician gets clinical fields. Watch for serializers that dump the entire database model into the response.
- Encryption: Are any PHI fields being returned in plaintext that should be encrypted in transit? Is the endpoint exclusively served over HTTPS (no HTTP fallback)? If the endpoint writes data, is field-level encryption applied before database insertion?
- Audit logging: Is every access to this endpoint audit-logged? Does the log capture the actor, the action, the resource, and the outcome? Are failed authorization attempts logged separately as security events? If this endpoint modifies data, are the old and new values captured in the audit trail?
- Input validation: Is the input validated and sanitized to prevent SQL injection and XSS (which could lead to PHI exposure)? Are path parameters and query parameters validated against expected formats?
- Error handling: Do error responses avoid leaking PHI or system internals? A 404 response for a patient that exists but the user cannot access should be indistinguishable from a 404 for a patient that does not exist (to prevent patient enumeration). Stack traces with PHI in request bodies should never appear in error responses.
- Rate limiting: Is the endpoint rate-limited to prevent bulk data harvesting? A compromised token should not be able to iterate through all patient IDs.
Design the authentication and session management flow for a HIPAA-compliant FastAPI application. Cover MFA, token lifecycle, and session termination.
Design the authentication and session management flow for a HIPAA-compliant FastAPI application. Cover MFA, token lifecycle, and session termination.
- Authentication flow: Step 1 — the user submits username and password over TLS. The password is verified against an Argon2id hash (not bcrypt, not SHA-256 — Argon2id is the current NIST recommendation for password hashing, resistant to both GPU and ASIC attacks). Step 2 — if credentials are valid, issue a temporary MFA challenge. The user provides a TOTP code from their authenticator app (or a WebAuthn/FIDO2 hardware key for higher security). Step 3 — if MFA succeeds, issue a short-lived JWT access token (15 minutes) and a longer-lived refresh token (7 days, stored server-side in Redis, not in a cookie).
- Token architecture: The access token is a signed JWT (RS256 with a rotating key pair) containing the user ID, roles, and session ID. It does not contain PHI. The access token is stateless — the API validates it without a database call. The refresh token is an opaque random string stored in Redis with the session metadata. When the access token expires, the client sends the refresh token to get a new access token. This refresh operation validates that the session is still active, the user is not locked, and the refresh token has not been revoked.
- Session management: Each user has at most N concurrent sessions (configurable, default 3). New logins beyond the limit either reject or terminate the oldest session. Session metadata in Redis tracks: user ID, login time, last activity time, IP address, user agent, and MFA verification status. The session timeout is 15 minutes of inactivity (HIPAA automatic logoff). Activity (any API call) resets the inactivity timer by updating last_activity in Redis.
- Session termination triggers: (1) Explicit logout — delete the session from Redis and add the current access token to a short-lived denylist. (2) Inactivity timeout — a background job sweeps Redis for expired sessions. (3) Password change — terminate all sessions for the user. (4) Account lockout (5 failed login attempts) — terminate all sessions. (5) Administrative revocation — the security team can terminate any user’s sessions immediately.
- The refresh token rotation pattern: every time a refresh token is used, issue a new one and invalidate the old one. If an attacker steals a refresh token and the legitimate user also uses it, the second use of the old token triggers a security alert and terminates all sessions for that user (detects token theft).
Your production HIPAA application is experiencing a security incident: someone is making authenticated API calls that extract patient data at an unusual rate. Walk me through how your application architecture helps you detect, contain, and investigate this.
Your production HIPAA application is experiencing a security incident: someone is making authenticated API calls that extract patient data at an unusual rate. Walk me through how your application architecture helps you detect, contain, and investigate this.
- Detection layer: The audit middleware captures every API call with the actor, resource, timestamp, and response size. The alert service runs real-time rules against the audit stream. Rule one: more than 100 patient record accesses per hour from a single user (baseline is 15-20) triggers a high-severity alert. Rule two: sequential patient ID access (iterating through IDs programmatically) triggers a critical alert. Rule three: bulk data export endpoints accessed more than once per day triggers an alert.
- Investigation layer: the correlation ID on every request links the suspicious API calls to a single session. From the session, I can see: the authenticated user, their IP address, the user agent (is it a browser or a script?), when the session started, and whether MFA was completed. The audit logs give me the exact sequence of API calls — which patients, which fields, what order, how fast. If the user agent shows a Python requests library or curl instead of a browser, that is strong evidence of automated exfiltration.
- Containment layer: the application supports session-level and user-level lockout without restarting anything. Step 1: revoke the session in Redis (immediate, sub-second). The next API call with the access token checks the session validity and returns 401. Step 2: if the account may be compromised, disable the user account in the database and flush all their sessions from Redis. Step 3: if the source IP is suspicious, add it to the WAF blocklist through the API gateway.
- Forensic layer: the complete audit trail gives the investigation team everything they need: exactly which patient records were accessed, which fields were viewed, whether any data was exported or printed, the complete request/response timeline, and the source of the session. Combined with network flow logs from the infrastructure layer, I can determine if data was exfiltrated to an external destination.
- Post-incident: the affected patient list comes directly from the audit logs (SELECT DISTINCT patient_id FROM audit_logs WHERE session_id = X). This list feeds into the breach notification process. The root cause analysis examines how the attacker obtained valid credentials and whether existing controls (rate limiting, anomaly detection thresholds) need adjustment.