Ist Supabase HIPAA-konform?

Supabase bietet ein HIPAA-Compliance-Add-on mit unterschriebenem Business Associate Agreement ab dem Team-Plan an. Das deckt die Datenbank- und Infrastrukturebene ab. Die Anwendung selbst muss trotzdem Zugriffskontrolle, Audit-Logging und Verschlüsselung korrekt implementieren, und es braucht ein eigenes BAA, bevor echte Patientendaten das System berühren.

Ist App Studio HIPAA- oder HDS-zertifiziert?

Nein, und keine Entwicklungsagentur kann das legitim sein. Weder HIPAA noch HDS kennen ein Zertifizierungsprogramm für Softwareagenturen. HDS zertifiziert die Hosting-Infrastruktur, HIPAA verlangt ein unterschriebenes BAA und technische Schutzmaßnahmen, die nachträglich von der US-Behörde HHS OCR geprüft werden. Wir wählen zertifizierte bzw. eignungsfähige Infrastruktur und implementieren Zugriffskontrolle, Audit-Logs und Verschlüsselung als Standard, nicht als Option.

Was ist der Unterschied zwischen HIPAA und der DSGVO für eine Gesundheits-App?

HIPAA ist ein US-Bundesgesetz, das speziell für Gesundheitsdaten bei amerikanischen Leistungserbringern, Versicherern und deren Dienstleistern gilt. Die DSGVO gilt EU-weit für alle personenbezogenen Daten, wobei Gesundheitsdaten nach Artikel 9 als besondere Kategorie strengeren Bedingungen unterliegen. Bei Nutzern in den USA und der EU müssen beide Rahmenwerke erfüllt werden, sie überschneiden sich bei Verschlüsselung und Zugriffsprotokollen, unterscheiden sich aber bei Einwilligung und Meldefristen.

Brauche ich HDS-Hosting, wenn meine App nur in Deutschland oder der EU außerhalb Frankreichs genutzt wird?

Nein. HDS (Hébergement de Données de Santé) ist eine französische Zertifizierung, die nur greift, wenn Gesundheitsdaten von Patienten betroffen sind, die in Frankreich behandelt werden. Ohne französische Patienten oder einen französischen Gesundheitsdienstleister als Kunden reicht DSGVO-konformes EU-Hosting aus.

Was ist ein Business Associate Agreement und wer muss eines unterschreiben?

Ein Business Associate Agreement (BAA) ist ein nach HIPAA vorgeschriebener Vertrag zwischen einer Covered Entity und jedem Dienstleister, der geschützte Gesundheitsdaten in ihrem Auftrag verarbeitet. Jeder Anbieter, der echte Patientendaten berührt, Entwicklungsagentur, Hosting-Provider, Drittanbieter, muss ein BAA unterschreiben, bevor die Daten fließen. Wer während der Entwicklung nur mit synthetischen Testdaten arbeitet, braucht keines.

HIPAA, DSGVO oder HDS? Compliance-Guide für Healthtech-Apps

"HIPAA-zertifiziert" gibt es nicht

Viele Agenturen werben mit "HIPAA-zertifiziert" oder "HDS-zertifiziert". Keine von ihnen besitzt diese Zertifizierung wirklich, weil es kein Zertifizierungsprogramm für Softwareagenturen gibt, weder in den USA noch in Frankreich. HIPAA ist ein Gesetz, keine Auszeichnung. Es gibt keine Prüfung, kein Zertifikat, keine Behörde, die eine App als "HIPAA-konform" abstempelt.

Was stattdessen existiert: gesetzliche Pflichten nach der HIPAA Security Rule, durchgesetzt im Nachhinein durch die US-Behörde HHS Office for Civil Rights, meist ausgelöst durch eine gemeldete Datenschutzverletzung. Compliance zeigt sich in unterschriebenen Verträgen, technischen Kontrollen und Dokumentation, nicht in einem Zertifikat.

Wer HIPAA wirklich betrifft

HIPAA gilt direkt für "Covered Entities" (Leistungserbringer, Versicherer, Abrechnungsstellen in den USA) und deren "Business Associates", jeden Dienstleister, der geschützte Gesundheitsdaten (PHI) in ihrem Auftrag verarbeitet. Eine Entwicklungsagentur wird zum Business Associate, sobald sie echte Patientendaten berührt, etwa in einer Staging-Umgebung mit Produktionsdaten oder durch fortlaufenden Hosting-Zugriff nach dem Launch.

Wird während der gesamten Entwicklung ausschließlich mit synthetischen Testdaten gearbeitet und erhält die Klinik erst nach der Übernahme des eigenen Hostings echte PHI, wird die Agentur unter Umständen nie zum Business Associate. Das ist eine echte architektonische Entscheidung, die man früh treffen sollte, weniger Berührungspunkte mit echten Patientendaten bedeuten eine kleinere Compliance-Angriffsfläche.

Die DSGVO für Gesundheitsdaten

Die DSGVO stuft Gesundheitsdaten nach Artikel 9 als "besondere Kategorie" ein, deren Verarbeitung grundsätzlich verboten ist, außer bei ausdrücklicher Ausnahme: explizite Einwilligung, Erforderlichkeit aus Gründen des öffentlichen Interesses im Gesundheitsbereich, oder Erforderlichkeit für die Gesundheitsversorgung. Das geht deutlich über die einfache Rechtsgrundlage "berechtigtes Interesse" hinaus, die für gewöhnliche personenbezogene Daten ausreicht.

Praktisch bedeutet das für eine DSGVO-konforme Gesundheits-App: dokumentierte, explizite Rechtsgrundlage für jede Verarbeitung von Gesundheitsdaten, Hosting in der EU, unterschriebener Auftragsverarbeitungsvertrag (AVV) mit jedem Dienstleister, Verschlüsselung im Ruhezustand und bei der Übertragung. Die Durchsetzung ist real: Europäische Behörden haben seit 2018 kumulierte Bußgelder von 7,1 Milliarden Euro verhängt, allein 1,2 Milliarden Euro im Jahr 2025 über mehr als 330 Verfahren, zunehmend gegen gewöhnliche SaaS-Unternehmen statt nur gegen Big Tech. Quellen: Kiteworks GDPR Enforcement 2026, CMS GDPR Enforcement Tracker.

HDS: relevant bei Patienten in Frankreich

HDS (Hébergement de Données de Santé) ist eine französische Zertifizierung nach Artikel L.1111-8 des Code de la santé publique, die für die Hosting-Infrastruktur gilt, sobald Gesundheitsdaten von in Frankreich behandelten Patienten gehostet oder verarbeitet werden. Anbieter wie OVHcloud, AWS, Microsoft Azure und Google Cloud verfügen über HDS-zertifizierte Regionen oder Angebote. Eine deutsche oder europäische Agentur, die für einen französischen Kunden baut, muss auf dieser zertifizierten Infrastruktur aufsetzen, wird dadurch aber selbst nicht "HDS-zertifiziert".

Ohne französische Patienten oder einen französischen Gesundheitsdienstleister als Kunden ist HDS nicht relevant, DSGVO-konformes EU-Hosting reicht aus.

Wo Supabase hineinpasst

Supabase, das Postgres-Backend, das wir für die meisten Projekte einsetzen, bietet ein HIPAA-Compliance-Add-on mit unterschriebenem BAA ab dem Team-Plan an. Das deckt Infrastrukturebene, verschlüsselte Speicherung und Netzwerksicherheit ab. Was es nicht automatisch tut: Row-Level-Security-Richtlinien korrekt schreiben, Audit-Logging als explizite Tabelle und Trigger aufbauen, automatische Sitzungsabmeldung und rollenbasierte Sichtbarkeit implementieren. Das bleibt Aufgabe der Anwendungsebene.

Wie wir Gesundheitsdaten-Apps architektieren

App Studio behauptet nie, "HIPAA-zertifiziert" oder "HDS-zertifiziert" zu sein, weil keine der beiden Aussagen zutreffen würde. Was wir bei jedem Gesundheitsdaten-Projekt tun: Hosting wählen, das HIPAA-eignungsfähig oder HDS-zertifiziert ist, je nachdem, wo die Patienten behandelt werden, BAA oder Hosting-Vertrag unterschreiben lassen, bevor echte Daten das System berühren, und Row-Level Security, Audit-Logging und rollenbasierte Zugriffskontrolle als Standardbestandteil bauen, nicht als Option.

Unsere Erfahrung mit sensiblen personenbezogenen Daten außerhalb eines klinischen HIPAA-Kontexts ist real: Wir haben das CRM für Schadensabwicklung und Streitfälle für Nostrum Care, die Tech-Tochter einer französischen Krankenversicherungsgruppe, gebaut, das sensible personenbezogene und finanzielle Daten nach DSGVO mit WeWeb, Supabase und n8n verarbeitet. Das sind Versicherungsdaten im Backoffice, keine klinischen Patientenakten, und wir beschreiben es bewusst so, es zeigt echte DSGVO-Erfahrung, ohne es als klinischen HIPAA- oder HDS-Einsatz darzustellen, der es nicht ist.

Checkliste vor dem Launch

Verträge: BAA mit Hosting-Provider unterschrieben; BAA mit der Entwicklungsagentur, falls sie nach dem Launch Zugriff behält; AVV mit jedem Drittanbieter, der PHI berühren könnte.

Zugriffskontrolle: eindeutige Anmeldedaten pro Nutzer, keine geteilten Konten; rollenbasierte Sichtbarkeit auf Datenbankebene über Row-Level Security, nicht nur in der Oberfläche versteckt; automatische Abmeldung nach Inaktivität.

Audit und Integrität: eine Audit-Log-Tabelle, die erfasst, wer wann welchen Datensatz eingesehen oder geändert hat; dieses Log selbst gegen Manipulation geschützt.

Verschlüsselung: AES-256 im Ruhezustand für jede Datenbank und jedes Backup; TLS 1.2 oder höher für jede Verbindung, intern wie extern.

Risikoanalyse: eine dokumentierte Risikoanalyse, die abdeckt, wo PHI gespeichert wird, wer darauf zugreifen kann und was schiefgehen könnte, die am häufigsten zitierte Lücke in echten HHS-OCR-Durchsetzungsmaßnahmen.