Ein Kunde rief mich an einem Donnerstagnachmittag im späten 2023 an — Fintech-to-Healthtech-Pivot, sie hatten gerade einen Compliance-Berater eingestellt, der sich ihre Next.js-Codebase ansah und eine dreiseitige Liste mit Problemen zurückgab. „Wir dachten, es auf AWS zu hosten, würde reichen", sagte der Gründer. Er glaubte das wirklich. Und ehrlich gesagt? Ich hatte diesen Satz vorher wahrscheinlich schon von sechs verschiedenen Teams gehört.
HIPAA-Compliance ist einer dieser Bereiche, in denen jeder denkt, er versteht die Oberfläche — eine BAA unterzeichnen, einen konformen Cloud-Provider wählen, fertig. Aber die HIPAA Security Rule interessiert sich nicht für die Marketingseite deines Hosting-Providers. Sie interessiert sich dafür, wie deine Anwendung Protected Health Information (PHI) handhabt, speichert, überträgt und prüft. Next.js — als Framework — ist von Haus aus weder konform noch nicht konform. Das, was du darauf aufbaust, ist alles.thinksthey understand the surface — sign a BAA, pick a compliant cloud provider, done. But theHIPAA Security Ruledoesn't care about your hosting provider's marketing page. It cares about how your application handles, stores, transmits, and audits Protected Health Information (PHI). Next.js — as a framework — is neither compliant nor non-compliant out of the box. What you build on top of it is everything.
Lass mich dich also durchgehen, was in 2026 wirklich zählt, basierend auf echten Architekturen, die ich gebaut habe, und echten Fehlern, die ich Teams machen gesehen habe.
---
Was „HIPAA-konforme Next.js" wirklich bedeutet
Manche verwechseln Infrastruktur-Compliance mit Anwendungs-Compliance. Das sind nicht dasselbe.
Dein Cloud-Provider (AWS, GCP, Azure — such dir einen aus) kann einen Business Associate Agreement mit dir abschließen. Das ist ein Rechtsdokument, das festlegt, dass er PHI auf seiner Infrastruktur nach HIPAA-Regeln schützt. AWS hat eine HIPAA-eligible services list, die es wert ist, gebookmarkt zu werden. Aber ein BAA von AWS bedeutet nicht, dass deine Next.js-App konform ist. Nicht einmal annähernd.HIPAA-eligible services listthat's worth bookmarking. But a BAA from AWS doesn't mean your Next.js app is compliant. Not even close.
Die Anwendungsschicht ist deine Verantwortung. Immer. Das Framework ist nur ein Transportmittel.yourresponsibility. Always. The framework is just a vehicle.
Hier ist das Ding — Next.js 14+ (und bis 2026 ist der App Router vollständig ausgereift) gibt dir Server-Komponenten, Server-Actions, Middleware und Edge Functions. Jede einzelne davon hat unterschiedliche Auswirkungen auf die PHI-Behandlung. Eine Server-Komponente, die eine Patientendatenbank abfragt und Daten an eine Client-Komponente weitergibt — wo liegen diese Daten? Wie lange? Landen sie in einem Browser-Cache? Das sind keine hypothetischen Bedenken.
---
Das PHI-Surface-Area-Problem
Bevor ich eine Zeile Code schreibe, lasse ich jeden Health-Tech-Client eine Übung machen: Jeden Ort abbilden, an dem PHI die Anwendung möglicherweise berühren könnte. Nicht wo es sie berühren sollte. Wo es sie könnte.shouldtouch it. Where itcould.
Das umfasst:
- URL-Parameter (ich habe Patienten-IDs in Query Strings gesehen — mach das nicht)
- Browser localStorage und sessionStorage
localStorageandsessionStorage - Client-seitige State-Verwaltung (Zustand Stores, Redux, sogar React Context)
- Next.js Fetch-Cache und die Data-Cache-Schicht
- Log-Ausgaben von console.log während der Entwicklung, die sich in die Produktion einschleichen
console.logduring development that sneaks into production - Error-Tracking-Tools wie Sentry (mehr dazu in Kürze)
- Analytics-Pipelines — GA4, Segment, Amplitude
Die letzten beiden sind für mehr Teams problematisch als fast alles andere. Anfang 2024 hatte Seahawk einen Telehealth-Client, der Sentry für Error-Monitoring eingebunden hatte. Ein Standard-Ansatz. Nur dass ihre Error Boundaries das vollständige Props-Objekt beim Absturz erfassten — das enthielt Termin-Details und User-Health-Flags. Sentry war nicht durch deren BAA abgedeckt. Das ist ein Datenschutzverstoß in spe.
Sanitärbereiche Ihres Error Tracking
Falls Sie Sentry mit PHI-nahem Code nutzen, verwenden Sie den beforeSend-Hook, um sensible Felder zu bereinigen, bevor sie den Browser verlassen. Punkt. Etwas wie das ist nicht verhandelbar:beforeSendhook to scrub sensitive fields before they leave the browser. Full stop. Something like this is non-negotiable:
`` beforeSend(event) { if (event.user) { delete event.user.email; delete event.user.ip_address; } return event; } ``beforeSend(event) { if (event.user) { delete event.user.email; delete event.user.ip_address; } return event; }``
Sentry hat einen HIPAA-Compliance-Pfad — sie unterzeichnen eine BAA — aber Sie müssen trotzdem konfigurieren, welche Daten Sie ihnen senden. Die BAA bereinigt Ihre Payloads nicht automatisch.HIPAA compliance path— they'll sign a BAA — but you still need to configure what data you send them. The BAA doesn't sanitise your payloads automatically.
---
Authentifizierung und Session-Verwaltung
Hier sehe ich die meisten Abkürzungen. Teams greifen zu NextAuth.js (jetzt Auth.js), verbinden einen Provider und sind fertig. Auth.js ist eine solide Bibliothek. Aber die Standards sind nicht die HIPAA-Standards.
Ein paar Besonderheiten:
- Session-Token-Speicherung — Auth.js setzt standardmäßig auf cookie-basierte Sessions, was in Ordnung ist, aber du musst httpOnly, secure und sameSite: 'strict' explizit setzen. Verlasse dich nicht auf die Standardeinstellungen.— Auth.js defaults to a cookie-based session, which is fine, but you need
httpOnly,secure, andsameSite: 'strict'explicitly set. Don't assume. - Session-Ablauf — HIPAAs Automatic Logoff Standard (§164.312(a)(2)(iii)) verlangt, dass Sessions nach einer definierten Inaktivitätszeit beendet werden. Die genaue Dauer ist nicht vorgeschrieben, aber 15 Minuten sind der Branchenstandard für klinische Anwendungen. Implementiere einen Inaktivitäts-Timer in deinem Layout. Ich baue das normalerweise als Custom Hook, der eine Server Action auslöst, um die Session ungültig zu machen.— HIPAA's Automatic Logoff standard (§164.312(a)(2)(iii)) requires that sessions terminate after a defined period of inactivity. The number isn't prescribed, but 15 minutes is the industry standard for clinical applications. Wire up an inactivity timer in your layout. I usually build this as a custom hook that fires a server action to invalidate the session.
- MFA — Nicht streng vorgeschrieben im HIPAA-Text, aber versuche einem OCR-Auditor zu erklären, warum du es nach einer Sicherheitsverletzung nicht implementiert hast. Nutze TOTP über etwas wie otplib oder verlasse dich auf einen Identity Provider wie Auth0 oder Clerk, der MFA bereits integriert hat und eine BAA unterzeichnet.— Not strictly mandated by HIPAA's text, but try explaining to an OCR auditor why you didn't implement it after a breach. Use TOTP via something like
otplibor lean on an identity provider like Auth0 or Clerk that has MFA baked in and will sign a BAA. - Audit Logging von Auth-Events — Jeder Login, fehlgeschlagene Login und Logout muss mit Zeitstempel und Benutzerkennung protokolliert werden. Jeden einzelnen.— Every login, failed login, and logout needs to be logged with a timestamp and user identifier. Every single one.
Ich werde dir nicht sagen, dass Auth.js für diesen Use Case falsch ist — ich habe es in der Produktion bei HIPAA-Projekten eingesetzt. Aber du musst die Compliance-Anforderungen bewusst obendrauf schichten.
---
Daten im Transit und in Ruhe
Transit ist der einfache Teil. TLS 1.2 mindestens, TLS 1.3 bevorzugt, überall. Nicht nur deine Hauptdomäne — deine API-Routen, deine Edge Functions, alle Webhooks. Wenn du auf Vercel bist, ist das erledigt. Wenn du auf EC2 selbst hostest oder Next.js in einem Docker-Container hinter einem NGINX Reverse Proxy laufen lässt, musst du das selbst konfigurieren. Ich habe Codebases überprüft, wo die internen Service-zu-Service-Aufrufe noch auf HTTP liefen, weil „es ist ja im VPC". Das ist keine akzeptable Position.
In Ruhe ist es schwieriger. Ein paar Punkte, die wichtig sind:
- Datenbankverschlüsselung — AWS RDS mit aktivierter Verschlüsselung (nutzt AES-256 über AWS KMS). Das ist eine Checkbox, aber du musst sie tatsächlich anhaken und dokumentieren.— AWS RDS with encryption enabled (uses AES-256 via AWS KMS). This is a checkbox, but you need to actually check it and document it.
- Verschlüsselung auf Feldebene für hochsensible Daten — Für Dinge wie Sozialversicherungsnummern, Diagnosen oder Medikamentenlisten füge ich oft eine zweite Verschlüsselungsebene auf Anwendungsebene hinzu und nutze dazu eine Bibliothek wie @aws-sdk/client-kms zum Wrappen/Unwrappen von Schlüsseln. Der Overhead ist real, aber das Risiko auch.— For things like SSNs, diagnoses, or medication lists, I often add a second layer of encryption at the application level using a library like
@aws-sdk/client-kmsto wrap/unwrap keys. Overhead is real, but so is the risk. - Next.js Data Cache — Das überrascht viele. Der App Router cached Fetch-Responses standardmäßig. Wenn du Patientendaten in einer Server Component mit fetch() abrufst, brauchst du { cache: 'no-store' }, es sei denn, du managst die Revalidation sehr bewusst. Eine gecachte Response mit PHI, die im Speicher oder Dateisystem des Servers liegt, ist ein Problem.— This one catches people out. The App Router caches fetch responses by default. If you're fetching patient data in a server component with
fetch(), you need{ cache: 'no-store' }unless you're very deliberately managing revalidation. A cached response containing PHI sitting in the server's memory or filesystem is a problem. - Backups — Verschlüsselt. Getestet. Dokumentiert. Offensichtlich, aber ich habe Systeme auditiert, bei denen die Backups existierten, aber noch nie wiederhergestellt worden waren.— Encrypted. Tested. Documented. Obvious, but I've audited systems where the backups existed but had never been restored once.
---
Audit Logging: Der Teil, den niemand bauen will
Ich sage das ganz deutlich — Audit Logging ist die langweiligste und zugleich wichtigste Sache, die du in einer Health-Tech-App bauen wirst. Jeder Zugriff auf PHI muss erfasst werden. Nicht nur Schreibzugriffe. Lesezugriffe auch.
Der HIPAA-Audit-Controls-Standard (§164.312(b)) verlangt „Hardware-, Software- und/oder verfahrenstechnische Mechanismen, die Aktivitäten in Informationssystemen aufzeichnen und prüfen, die ePHI enthalten oder nutzen." Praktisch bedeutet das: Sie benötigen ein unveränderliches Protokoll, wer auf welche Patientendaten zugegriffen hat, wann und von wo.HIPAA Audit Controls standard(§164.312(b)) requires "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI." What that means practically: you need an append-only log of who accessed what patient data, when, and from where.
Ich baue das als Middleware-Layer in Next.js. Für App-Router-Projekte intercepte ich in middleware.ts für Route-Level-Logging und füge einen dünnen Service-Wrapper um jede Datenbankabfragefunktion herum ein, die PHI-Tabellen berührt. Die Log-Einträge werden in eine separate Datenbanktabelle geschrieben (oder in einen Service wie AWS CloudTrail, wenn Sie Unveränderlichkeitsgarantien wollen) — niemals in dieselbe Tabelle wie die PHI selbst.middleware.tsfor route-level logging and add a thin service wrapper around any database query function that touches PHI tables. The log records get written to a separate database table (or a service like AWS CloudTrail if you want immutability guarantees) — never the same table as the PHI itself.
Ein minimaler Audit-Datensatz sieht so aus:
user_id — wer— whoresource_type + resource_id — was+resource_id— whataction — read / write / delete— read / write / deleteip_address — wo (Anonymisierung auf der Netzwerkschicht ist ausreichend)— where (anonymised at the network layer is fine)timestamp (UTC, immer UTC)(UTC, always UTC)request_id — um die Korrelation mit Ihren Anwendungsprotokollen herzustellen— to correlate with your application logs
Erlauben Sie Entwicklern nicht, console.log(patientRecord) zu verwenden und das als Audit-Trail zu bezeichnen. Ich habe das schon gesehen. Das ist es nicht.console.log(patientRecord)and call it an audit trail. I've seen this. It's not.
---
Wahl deines Infrastructure-Stacks
Die ehrliche Antwort ist, dass es 2026 nur eine handvoll Stacks gibt, die ich für eine produktive HIPAA Next.js-Anwendung wirklich empfehlen würde.
Vercel + PlanetScale/Neon + Clerk ist der Developer-Experience-Stack. Vercel wird eine BAA unterzeichnen (Enterprise-Plan — ja, das kostet Geld). PlanetScale und Neon haben beide HIPAA-geeignete Tiers. Clerk kümmert sich um die Authentifizierung und wird eine BAA unterzeichnen. Das ist schnell zum Ausliefern und angemessen zu betreiben. Der Kompromiss ist der Kostenaufwand bei Skalierung und ein gewisser Verlust an Infrastruktur-Kontrolle.is the developer-experience stack. Vercel will sign a BAA (enterprise plan — yes, it costs money). PlanetScale and Neon both have HIPAA-eligible tiers. Clerk handles auth and will sign a BAA. This is fast to ship and reasonable to operate. The tradeoff is cost at scale and some loss of infrastructure control.
AWS (ECS/EKS für die Next.js-App) + RDS Aurora + Cognito ist der Enterprise-Stack. Mehr operativer Aufwand. Viel mehr Kontrolle. AWs Shared-Responsibility-Modell ist gut dokumentiert und die BAA-Abdeckung ist breit. Wenn dein Kunde ein Krankenhaussystem oder ein Versicherer ist, werden sie wahrscheinlich deine AWS-Architektur im Detail nachfragen.is the enterprise stack. More operational overhead. Much more control. AWS's shared responsibility model is well-documented and the BAA coverage is broad. If your client is a hospital system or an insurer, they're probably going to ask about your AWS architecture in detail.
Render oder Railway — ich würde das für alles mit ernsthafter Regulierung vermeiden. Es sind großartige Tools, aber ihre HIPAA-Compliance-Geschichte ist dünn.— I'd steer clear for anything seriously regulated. They're great tools, but their HIPAA compliance story is thin.
Eine Sache, die ich hervorheben möchte: Verzels Edge Network und Edge Functions sind ab Anfang 2026 nicht HIPAA-abgedeckt unter ihrer BAA. Wenn du Logik ausführst, die PHI in Edge-Middleware berührt, gibt es eine Lücke. Führe diese Logik stattdessen in Serverless Functions (Node.js-Runtime) aus.notHIPAA-covered under their BAA as of early 2026. If you're running logic that touches PHI in edge middleware, that's a gap. Run that logic in serverless functions (Node.js runtime) instead.
---
Third-Party-Integrationen: Wo die Compliance stirbt
Jeder Third-Party, den du integrierst und der PHI berührt, braucht eine BAA. Das klingt offensichtlich. Hier ist die Liste, die Teams tatsächlich stolpern lässt:
- Customer-Support-Tools (Intercom, Zendesk) — wenn ein Patient über seine Gesundheit schreibt, sind das PHI in deiner Support-Plattform
- Formular-Tools (Typeform, Jotform) — Patientenaufnahmformulare sind PHI
- E-Mail-Provider (SendGrid, Postmark) — wenn der E-Mail-Body Gesundheitsinformationen enthält, ist eine BAA erforderlich
- Feature-Flag-Tools (LaunchDarkly, Statsig) — normalerweise kein Problem, aber wenn du Benutzerattribute mit Gesundheitsstatus an die Flag-Auswertung übergibst, das ist PHI
- CRMs (HubSpot, Salesforce) — viele Healthtech-Teams synchronisieren Patientendaten einfach in diese Systeme, ohne nachzudenken
Postmark unterzeichnet eine BAA. SendGrid (über Twilio) auch, bei kostenpflichtigen Plänen. Twilio für SMS ebenfalls. LaunchDarkly hat einen BAA-Weg. Das sind keine obskuren Optionen — der BAA-Prozess ist meist ein Formular und ein paar Werktage.
Die, die keine BAA unterzeichnen oder können? Integriere sie nirgendwo in der Nähe von PHI. So einfach ist das.
---
FAQ
Macht die Bereitstellung auf Vercel meine Next.js-App HIPAA-konform?
Nein. Vercel kann eine Business Associate Agreement auf ihrem Enterprise-Plan unterzeichnen, was bedeutet, dass sie bestimmte HIPAA-Verpflichtungen für die Infrastruktur übernehmen, die sie kontrollieren. Aber dein Anwendungscode, dein Datenbankdesign, dein Logging, deine Third-Party-Integrationen — nichts davon ist durch Veels BAA abgedeckt. Compliance ist über alle Schichten des Stacks verteilt, und die Application Layer ist deine Verantwortung.
Muss ich Daten in einer Next.js API Route vor dem Senden an den Client verschlüsseln?
TLS kümmert sich um die Verschlüsselung im Transit, daher musst du den HTTP-Response-Body nicht manuell verschlüsseln. Was du tun musst, ist sicherzustellen, dass du nur die für die Operation mindestens notwendigen PHI zurückgibst — nicht vollständige Patientendatensätze, wenn du nur einen Namen brauchst. Das Prinzip der "Minimalen Notwendigkeit" ist in HIPAA verankert und sollte dein API-Response-Design von Tag eins an prägen.
Ist das integrierte Caching des Next.js App Routers sicher für PHI?
Nicht standardmäßig. Der Data Cache und Full Route Cache im App Router können Responses mit PHI cachen, was problematisch ist. Für jede Route oder jeden Fetch-Call, der Patientendaten berührt, verwende { cache: 'no-store' } bei Fetch-Calls und füge export const dynamic = 'force-dynamic' zu Route Segments hinzu. Lies Veels Caching-Dokumentation sorgfältig durch — sie ist dicht, aber wichtig.{ cache: 'no-store' }on fetch calls and addexport const dynamic = 'force-dynamic'to route segments. Review Vercel'scaching documentationcarefully — it's dense but important.
Welches Minimum-Logging brauche ich für einen HIPAA-Audit-Trail?
Mindestens: wer hat auf was zugegriffen, wann und von wo. Das sind User ID, Resource-Identifier, Action-Typ, Zeitstempel und IP-Adresse. Logs müssen manipulationssicher sein (Append-only, nicht von Anwendungscode änderbar) und aufbewahrt werden — die meisten Compliance-Frameworks empfehlen sechs Jahre, was HIPAAs Dokumentationserstellungsanforderung entspricht.
Kann ich React Query oder SWR in einer HIPAA-App für Data Fetching verwenden?
Ja, aber mit Vorsicht. Beide Bibliotheken cachen Responses client-seitig, was bedeutet, dass PHI im Browser-Memory liegen kann. Setze staleTime: 0 und cacheTime: 0 (React Query) oder dedupingInterval: 0 (SWR) für Queries, die PHI zurückgeben. Lösche auch den Query Cache bei Logout explizit — verlasse dich nicht darauf, dass das Component Unmounting das übernimmt.staleTime: 0andcacheTime: 0(React Query) ordedupingInterval: 0(SWR) for queries that return PHI. Also clear the query cache on logout explicitly — don't rely on component unmounting to handle this.
---
Ich will ehrlich sein: HIPAA-Compliance ist wirklich schwierig umzusetzen, und kein Framework — Next.js oder sonst eins — macht es einfach. Die Teams, die es gut hinbekommen, sind diejenigen, die es von Anfang an als Architekturfrage behandeln, nicht als Checkliste, die man vor dem Launch abarbeitet. Das Framework ist in Ordnung. Die Lücken liegen fast immer in den Entscheidungen, die man drumherum trifft.
Fangen Sie mit der Kartierung der PHI-Oberfläche an. Alles andere folgt daraus.