Skip to main content

Capstone Project: SecureHealth Platform

This capstone project challenges you to build a fully HIPAA-compliant healthcare application from the ground up. You’ll implement all the security controls, compliance measures, and best practices covered throughout this course.
Time Commitment: This project is designed for 40-60 hours of work over 4-6 weeks. Each phase builds on the previous, creating a production-ready healthcare platform.

Project Overview

What You’ll Build

SecureHealth - A patient portal and clinical management system featuring:

Patient Portal

Secure patient access to records, appointments, and messaging

Clinical Interface

Provider-facing system for patient management and documentation

Admin Dashboard

Compliance monitoring, audit logs, and system administration

Integration APIs

HIPAA-compliant APIs for third-party integrations

Technology Stack


Phase 1: Foundation & Architecture (Week 1)

Objectives

  • Set up secure development environment
  • Design database schema with PHI classification
  • Implement core security infrastructure
  • Create project structure following security best practices

1.1 Project Setup

1

Repository Structure

Create project with security-focused structure:
2

Security Configuration

Implement centralized security configuration:
3

Database Schema Design

Design PHI-aware database schema:

1.2 Encryption Service

Implement the encryption service for PHI:

Phase 1 Deliverables

  • Project repository with security-focused structure
  • Database schema with PHI classification
  • Encryption service with key management integration
  • Development environment with secrets management
  • Initial security documentation

Phase 2: Authentication & Access Control (Week 2)

Objectives

  • Implement secure authentication with MFA
  • Build role-based access control (RBAC)
  • Create session management with security controls
  • Implement break-glass procedures

2.1 Authentication System

2.2 Role-Based Access Control

Phase 2 Deliverables

  • Authentication service with MFA
  • RBAC implementation with minimum necessary
  • Session management with security controls
  • Break-glass procedure implementation
  • Password policy enforcement

Phase 3: Audit Logging & Monitoring (Week 3)

Objectives

  • Implement comprehensive audit logging
  • Create PHI access tracking
  • Build anomaly detection system
  • Design audit reporting for compliance

3.1 Audit Logging Service

Phase 3 Deliverables

  • Comprehensive audit logging for all PHI access
  • Authentication event logging
  • Anomaly detection rules
  • Accounting of Disclosures report
  • Audit log integrity verification

Phase 4: API Security & Integration (Week 4)

Objectives

  • Build secure REST API with HIPAA controls
  • Implement API rate limiting and throttling
  • Create secure third-party integration patterns
  • Build data validation and sanitization

4.1 Secure API Endpoints

Phase 4 Deliverables

  • Secure API endpoints with authentication
  • Permission-based access control on all endpoints
  • Request/response validation
  • Rate limiting implementation
  • API documentation with security notes

Phase 5: Infrastructure & Deployment (Week 5)

Objectives

  • Deploy to HIPAA-eligible cloud infrastructure
  • Implement infrastructure as code
  • Configure security monitoring
  • Set up backup and disaster recovery

5.1 Terraform Infrastructure

Phase 5 Deliverables

  • HIPAA-compliant AWS infrastructure
  • Terraform modules for all components
  • Security groups with least privilege
  • CloudTrail and CloudWatch configuration
  • Backup and DR procedures

Phase 6: Testing & Compliance Validation (Week 6)

Objectives

  • Security testing (penetration testing prep)
  • Compliance checklist validation
  • Documentation completion
  • Final review and sign-off

6.1 Security Testing Checklist

6.2 Compliance Checklist

Access Control (§164.312(a))
  • Unique user identification
  • Emergency access procedure (break-glass)
  • Automatic logoff
  • Encryption and decryption
Audit Controls (§164.312(b))
  • Audit log mechanism implemented
  • Logs retained for 6 years
  • Log integrity verification
  • Regular log review process
Integrity (§164.312(c))
  • Authentication of ePHI
  • Change detection mechanism
Transmission Security (§164.312(e))
  • Integrity controls
  • Encryption in transit (TLS 1.2+)
Administrative Safeguards
  • Risk analysis documented
  • Risk management plan
  • Sanction policy
  • Information system activity review
Technical Policies
  • Access authorization policy
  • Workstation use policy
  • Device and media controls
  • Audit controls policy

Phase 6 Deliverables

  • Complete security test suite
  • Penetration testing report (if applicable)
  • Compliance checklist completed
  • Risk assessment documentation
  • Policies and procedures documentation
  • User training materials

Grading Rubric


Submission Requirements

  1. Code Repository
    • Complete source code
    • README with setup instructions
    • Environment configuration (without secrets)
  2. Documentation
    • Architecture diagram
    • Security controls documentation
    • Risk assessment summary
    • Policies and procedures
  3. Demo
    • Working deployment (local or cloud)
    • Walkthrough of security features
    • Audit log demonstration
  4. Testing
    • Security test results
    • Compliance checklist (completed)
    • Any penetration testing results

Congratulations!

Upon completing this capstone, you will have:

Built Real Security

A production-ready HIPAA-compliant healthcare application

Practical Experience

Hands-on implementation of encryption, access control, and auditing

Compliance Knowledge

Deep understanding of HIPAA technical requirements

Portfolio Project

A substantial project demonstrating healthcare security expertise
Good luck with your capstone project!

Interview Deep-Dive

Strong Answer:
  • The single biggest security risk is the key management layer — specifically, the concentration of decryption capability in HashiCorp Vault or AWS KMS. If the key management system is compromised, the attacker can decrypt every piece of PHI in the database, every encrypted message, and every encrypted backup. Every other security control (RBAC, audit logging, network segmentation) becomes irrelevant if the attacker has the keys.
  • How I mitigated this: First, the key management system runs in its own isolated security zone with no direct internet access, restricted network paths, and a dedicated security group. Only the application’s encryption service can reach Vault, and only from specific private subnet IPs. Second, Vault is configured with auto-unseal using a cloud KMS key (avoiding the operational risk of manual unseal keys) but the auto-unseal key itself requires IAM authentication with MFA and condition keys. Third, the key hierarchy uses envelope encryption so that a Vault compromise does not immediately expose data — the attacker needs both Vault access AND database access. Fourth, Vault’s own audit log tracks every key operation (encrypt, decrypt, rotate, create) and feeds into the SIEM with real-time alerting on anomalous patterns (unusual volume of decrypt operations, access from unexpected IPs, access outside business hours). Fifth, key material is never exported from Vault — the application sends data to Vault for encryption/decryption rather than extracting keys and using them locally. This means there is no key material in application memory to be dumped by an attacker who compromises the application server.
  • The defense-in-depth principle: no single compromise should lead to total data exposure. An attacker who compromises the application server cannot decrypt without Vault access. An attacker who compromises Vault cannot read data without database access. An attacker who compromises the database sees only ciphertext without Vault access.
Follow-up: During a penetration test, the testers obtain a valid application token and demonstrate they can call the encryption service API to decrypt arbitrary records. What went wrong and how do you fix it?The flaw is in the authorization check at the encryption service layer. The encryption service accepted any valid application token and decrypted any record — it did not enforce per-patient or per-role authorization on decrypt operations. This means the encryption is effectively “all or nothing” once you are authenticated. The fix: implement encryption context binding. Every encryption operation includes a context (patient_id, requesting_role) that is bound to the ciphertext as Additional Authenticated Data (AAD). At decryption time, the caller must provide the same context, and the encryption service verifies that the requesting user is authorized to access that specific patient. If the user’s role does not permit access to that patient, the decryption request is denied even though the ciphertext is valid and the key is available. Additionally, implement rate limiting on the decryption API — a single token should not be able to decrypt more than a reasonable number of records per time period. This is the intersection of access control and encryption that many architectures miss.
Strong Answer:
  • At 10x traffic, the first bottleneck is the encryption/decryption layer. Every PHI read requires DEK unwrapping (KMS API call) and AES decryption. At 10x, the KMS API rate limits become the constraint — AWS KMS has a default limit of 5,500 requests per second per region for symmetric operations. If each patient record read requires one KMS call, and you are doing 5,000 reads per second, you are already at the limit. Mitigation: implement DEK caching. Cache unwrapped DEKs in application memory for their rotation period. This converts N KMS calls per patient into 1 KMS call per DEK, with all subsequent decryptions using the cached key. This alone provides 100-1000x improvement in the encryption layer.
  • The second bottleneck is the PostgreSQL connection pool. Async SQLAlchemy uses a connection pool, but at 10x traffic, you exhaust the pool and requests queue. The encrypted columns (BYTEA type) are also larger than plaintext, increasing I/O per query. Mitigation: add read replicas for read-heavy workloads (patient record lookups), tune the connection pool size, and implement database-level connection pooling with PgBouncer.
  • The third bottleneck is the audit logging pipeline. At 10x traffic, the audit logger processes 10x events. If the flush interval and batch size are not tuned, the in-memory buffer grows unbounded or flush operations back-pressure the API. Mitigation: increase the batch size (from 100 to 500), use async writes exclusively, and add a message queue (Kafka or SQS) between the audit service and the database so that audit log writes are fully decoupled from API request handling.
  • The fourth bottleneck is Redis session management. At 10x concurrent users, Redis memory usage increases linearly. Each session stores metadata plus last-activity timestamps updated on every request. At 10x, you are doing 10x Redis writes per second for activity tracking. Mitigation: batch activity updates (update Redis every 30 seconds instead of every request), use Redis Cluster for horizontal scaling, and tune session TTLs to free memory faster.
  • What does NOT break: the RBAC policy evaluation (in-memory, no external calls), TLS termination (handled by the load balancer, scales horizontally), and the FastAPI application itself (async framework handles concurrent requests efficiently with more workers).
Follow-up: Your KMS DEK caching strategy means decrypted key material sits in application memory. What is the security implication and how do you mitigate it?The security implication is that a memory dump of the application process (via a debug endpoint, core dump, or memory exploitation) could expose cached DEKs. Mitigations: (1) Use short cache TTLs (5-15 minutes) so DEKs are only in memory briefly. (2) Run the application in a hardened container with no debug endpoints, core dumps disabled (ulimit -c 0), and ptrace restricted (Seccomp or AppArmor profile). (3) Use encrypted memory if the hardware supports it (AMD SEV on cloud instances encrypts memory at the hardware level). (4) Implement a secure memory allocator that zeroes memory on free, preventing DEK remnants from persisting after cache eviction. (5) Limit the number of cached DEKs to the active working set (currently accessed patients), not all DEKs ever used. The tradeoff between caching and security is real, but without caching, the system cannot handle production load. The mitigations reduce the exposure window and attack surface to an acceptable level.
Strong Answer:
  • Section 164.312(b) requires: “Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.” I would present a comprehensive demonstration covering four areas.
  • Area one — what we log: demonstrate the audit event schema capturing the complete W5 for every PHI interaction. Show live audit events being generated by normal platform operations: a patient login (authentication event), viewing a record (PHI access event), a provider updating a note (PHI modification event with old/new values), and a failed authorization attempt (security event). Show that the event captures actor identity, timestamp, resource, action, outcome, and data fields accessed.
  • Area two — how we store and protect logs: show the PostgreSQL audit_logs table with append-only triggers preventing UPDATE and DELETE. Demonstrate the hash chain by showing two consecutive events and verifying the previous_hash linkage. Show the digital signature verification on a sample event using the public key. Show the partition strategy and retention configuration (7 years of monthly partitions). Show the role separation — the auditor role has SELECT-only access, the application role has INSERT-only access, no role has UPDATE or DELETE.
  • Area three — how we examine logs: demonstrate the audit dashboard showing real-time event streaming, filterable by event type, actor, patient, and time range. Show the anomaly detection alerts: a simulated brute-force login attempt triggering a threshold alert, a break-glass access generating an immediate critical alert. Run the chain integrity verification tool against the last 24 hours and show a clean verification report with zero errors.
  • Area four — how we maintain the system: show the daily automated integrity verification checkpoints and their stored results. Show the archival pipeline moving old partitions to encrypted cold storage. Show the quarterly access review process where the compliance team reviews who has access to audit logs. Show the incident response integration: when an alert fires, it creates a ticket in the incident management system with a link to the relevant audit events.
  • Close with: “Section 164.312(b) requires mechanisms to record and examine. We record comprehensively with tamper-proof integrity, and we examine through real-time alerting, dashboards, and scheduled reviews. Here is the documentation that describes all of this for your compliance file.”
Follow-up: The auditor asks how you would detect if your audit logging system itself was silently failing — events happening but not being recorded.This is a subtle and important question. Several mechanisms: (1) Heartbeat events: the audit system generates a synthetic “health check” event every 60 seconds. A monitoring system verifies that these heartbeats appear in the audit log. If a heartbeat is missing, the monitoring system alerts immediately. (2) Cross-correlation: the API gateway logs request counts independently of the audit system. We periodically compare the gateway’s request count for PHI endpoints against the audit log’s event count. A discrepancy indicates dropped events. (3) Application-level verification: after logging a critical event (PHI export, break-glass, account creation), the application queries the audit log to confirm the event was recorded. If the confirmation fails, the application blocks the operation and alerts. (4) Buffer monitoring: the in-memory audit buffer has a maximum size. If the buffer is consistently near capacity, it means events are being generated faster than they can be flushed — a leading indicator of potential event loss. Alert on buffer utilization exceeding 80%. These mechanisms ensure that we detect audit system failures within minutes, not during the next quarterly review.