Fassen Sie diesen Artikel mithilfe von KI zusammen
Eine Website für eine Praxis, Klinik oder Gesundheitsorganisation auf Webflow zu bauen bedeutet, hochwertiges, patientenzentriertes Design mit strengen regulatorischen Vorgaben zu verbinden. Webflow bietet von sich aus keine Zertifizierung für die Verarbeitung von Gesundheitsdaten und keinen speziell auf Gesundheitsdaten zugeschnittenen Auftragsverarbeitungsvertrag (AVV) mit den dafür erforderlichen technischen Garantien. Patientendaten dürfen daher nicht direkt über Webflow gespeichert oder verarbeitet werden.
Die in der Praxis bewährte Lösung ist eine entkoppelte Drei-Schichten-Architektur:
- Die öffentliche Marketing-Schicht: Webflow hostet sicher den öffentlichen Teil der Website, etwa Ärzteprofile, Standortseiten und barrierefreie Layouts.
- Die Grenze zu Gesundheitsdaten: Klare Design-Vorgaben stellen sicher, dass keine nativen Webflow-Formulare oder Chat-Widgets identifizierbare Gesundheitsangaben erfassen.
- Die vertraglich abgesicherte Schicht: Jede interaktive Patientenaktion, etwa Terminanfragen, Anamnesebögen oder Patientenportal-Logins, wird an einen dedizierten, vertraglich geeigneten Drittanbieter übergeben.
Zusätzlich müssen Tracking-Pixel wie Google Analytics oder Meta sorgfältig geprüft werden, um Datenlecks zu vermeiden und einen DSGVO-konformen Weg von der Suchmaschine bis zum Patientenportal sicherzustellen.
Ist Webflow DSGVO-konform für eine Gesundheitswebsite?
Nicht ohne Weiteres. Webflow bietet keine spezielle Zertifizierung für die Verarbeitung von Gesundheitsdaten und keinen Auftragsverarbeitungsvertrag, der die besonderen Anforderungen an Daten nach Art. 9 DSGVO (besondere Kategorien personenbezogener Daten, einschließlich Gesundheitsdaten) abdeckt. Das ist die direkte Antwort auf die Frage, die sich die meisten Praxen und Gesundheitsteams zuerst stellen, und sie sollte klar am Anfang dieses Leitfadens stehen, weil sie bestimmt, wie eine Gesundheitswebsite auf Webflow aufgebaut sein muss, nicht ob Webflow grundsätzlich genutzt werden kann.
Nach DSGVO und dem deutschen Bundesdatenschutzgesetz (BDSG) braucht jeder Auftragsverarbeiter, der Gesundheitsdaten im Namen einer verantwortlichen Stelle verarbeitet, einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO mit konkreten technischen und organisatorischen Maßnahmen (TOMs). Webflow schließt diesen spezifisch auf Gesundheitsdaten zugeschnittenen Vertrag nicht ab und bietet auch nicht die Verschlüsselung und Protokollierung, die für besonders sensible Datenkategorien erwartet wird.
Das bedeutet nicht, dass Webflow grundsätzlich unsicher ist. Der Enterprise-Tarif verfügt über eine SOC 2 Type II-Zertifizierung, ein unabhängiges Audit allgemeiner Sicherheitskontrollen, und das ist ein echtes, nachprüfbares Gütesiegel. Es ist nur ein anderer, engerer Geltungsbereich als ein spezieller AVV für Gesundheitsdaten: SOC 2 zeigt, dass Webflow die Infrastruktursicherheit ernst nimmt, ersetzt aber nicht die spezifischen vertraglichen und technischen Garantien, die für die Verarbeitung von Gesundheitsdaten erforderlich sind.
Für Agenturen oder Organisationen mit Patienten in den USA, oder die auf beiden Märkten aktiv sind, stellt sich die gleiche Frage gespiegelt unter HIPAA: Webflow unterschreibt kein Business Associate Agreement (BAA) und ist damit aus denselben strukturellen Gründen auch nicht HIPAA-konform.
In der Praxis bleibt Webflow eine ausgezeichnete Plattform für den öffentlichen, marketingorientierten Teil einer Gesundheitswebsite, solange keine identifizierbaren Gesundheitsdaten tatsächlich über die Plattform laufen. Dieser Leitfaden zeigt genau, wo diese Grenze verläuft und wie eine Gesundheitswebsite so aufgebaut wird, dass Webflow das übernimmt, was es gut kann, während alles, was Gesundheitsdaten betrifft, an anderer Stelle verarbeitet wird. Dies ist eine allgemeine technische Einordnung, keine Rechtsberatung. Lassen Sie Ihre konkrete Compliance-Situation vor dem Launch von einer Datenschutz- oder Gesundheitsrechtskanzlei prüfen.
Was auf einer Website als Gesundheitsdaten zählt (mehr, als man denkt)
Gesundheitsdaten sind nach Art. 9 DSGVO eine besondere Kategorie personenbezogener Daten mit verschärftem Schutzniveau. Auf einer Website geht das deutlich über die klassische Patientenakte hinaus: Es ist jede Kombination aus einer identifizierenden Angabe (Name, E-Mail, Telefonnummer) mit einem gesundheitsbezogenen Kontext. Häufige, leicht übersehene Erfassungspunkte sind:
- Eine Symptombeschreibung in einem offenen Textfeld eines Kontaktformulars
- Eine Terminanfrage, die eine Diagnose oder den behandelnden Arzt nennt
- Ein Anamnese- oder Überweisungsformular
- Ein Login zum Patientenportal
- Ein Upload-Feld für Versicherungskarten oder Überweisungsschreiben
- Ein Chat-Widget, das vollständige Gesprächsverläufe speichert, in denen ein Besucher seinen Zustand beschreibt
- Ein Formularfeld mit Autovervollständigung, das der Browser manchmal mit zuvor eingegebenen, gesundheitsnahen Angaben befüllt
- Eine URL-Struktur, bei der ein Patientenportal-Link eine Termin-ID oder einen Diagnosecode als Parameter enthält, der in Server-Logs oder Analytics-Tools landen kann
Ein generisches Kontaktformular, das nur Name und Telefonnummer abfragt, ist in der Regel unproblematisch. Dasselbe Formular mit einem Feld wie „Worum geht es bei Ihrem Anliegen" wird in dem Moment zu einem Gesundheitsdaten-Erfassungspunkt, in dem eine echte Person ein echtes Symptom eintippt. Genau hier rutschen die meisten Gesundheitswebsites in die Nichtkonformität, oft ohne dass jemand das bewusst entschieden hätte.
Ein gut gemeintes „Schildern Sie uns Ihre Situation"-Feld in einem nativen Webflow-Formular kann aus einer ansonsten konformen Marketingseite einen Erfassungspunkt für Gesundheitsdaten machen, verarbeitet über eine Plattform ohne dafür geeigneten Vertrag.
Das Tracking-Pixel-Problem, das die meisten Gesundheitswebsites unterschätzen
Dieser Punkt verdient einen eigenen Abschnitt, weil es sich um ein echtes, deutlich unterschätztes Risiko handelt, das nichts mit Formularen zu tun hat, und das in den USA einige der größten gesundheitsdatenbezogenen Vergleiche der jüngeren Zeit ausgelöst hat. Standardkonfigurationen von Google Analytics und Meta Pixel, die auf praktisch jeder kommerziellen Website laufen, gerieten im Dezember 2022 ins Visier der US-Aufsichtsbehörde HHS Office for Civil Rights, die klarstellte, dass Tracking-Technologien, die identifizierbare Gesundheitsinformationen ohne ordnungsgemäße Einwilligung übermitteln, gegen HIPAA verstoßen, unabhängig davon, ob der Empfänger ein traditioneller Gesundheitsdienstleister ist oder nicht.
Die finanziellen Folgen waren erheblich: Advocate Aurora Health stimmte einem Vergleich über 12,225 Millionen US-Dollar zu, nachdem Meta Pixel und Google Analytics auf Website, App und Patientenportal Daten potenziell für die gesamte Patientenbasis von rund 3 Millionen Menschen offengelegt hatten. Das war kein Einzelfall: MarinHealth (3 Millionen US-Dollar), Jefferson Healthcare, Reid Health und mehrere weitere Gesundheitssysteme erreichten vergleichbare Vergleiche, und laufende Verfahren haben mehr als 660 Krankenhaussysteme identifiziert, bei denen Meta Pixel Patientendaten empfangen hat.
Der Mechanismus ist unauffällig: Ein Pixel braucht keine Formularübermittlung, um Gesundheitsdaten preiszugeben. Navigiert ein Besucher von einer Seite mit dem Titel „Terminbestätigung Onkologie", während er im Patientenportal eingeloggt ist, oder enthält die URL selbst einen Diagnosenamen, kann ein Standard-Analytics- oder Retargeting-Pixel diesen Seitenkontext, kombiniert mit identifizierenden Signalen wie IP-Adresse oder Login-Cookie, an einen Dritten übermitteln, der nie für den Empfang solcher Daten vorgesehen war.
Für eine Gesundheitswebsite mit der unten beschriebenen Drei-Schichten-Architektur bedeutet das praktisch, Analytics- und Werbetools mit derselben Sorgfalt zu prüfen wie Formulare. Unter der DSGVO ist die rechtliche Lage ebenso ernst: Eine unzulässige Verarbeitung von Gesundheitsdaten nach Art. 9 DSGVO kann Bußgelder von bis zu 4 % des weltweiten Jahresumsatzes oder 20 Millionen Euro nach sich ziehen, und die deutschen Datenschutzaufsichtsbehörden prüfen Tracking und Einwilligungsmanagement zunehmend konsequent, besonders im Gesundheitsbereich. Standard-Google-Analytics und Meta-Pixel-Implementierungen sind auf der öffentlichen Marketing-Schicht (eine Leistungsseite, ein Blogbeitrag, eine Standortseite) vertretbar, solange kein gesundheitsbezogener Kontext (Seitentitel, URL-Parameter, Referrer-Daten) sie jemals erreicht.
Sie dürfen jedoch nie hinter dieser Grenze auftauchen, auch nicht auf einem Patientenportal oder Terminbuchungstool, an das ein Besucher weitergeleitet wird, selbst wenn dieses Tool selbst vertraglich für Gesundheitsdaten abgesichert ist. Ein generisches Marketing-Pixel an dieser Stelle würde den gesamten Zweck der Auslagerung der Gesundheitsdaten an ein konformes Tool zunichtemachen.
Die Drei-Schichten-Architektur für eine Gesundheitswebsite auf Webflow
Die praktische Lösung besteht nicht darin, Webflow zu vermeiden, sondern die Website so zu strukturieren, dass Gesundheitsdaten niemals die native Formularverarbeitung, das CMS oder die Hosting-Schicht von Webflow erreichen. Beim Aufbau einer Gesundheitswebsite auf Webflow kommen drei Schichten zum Einsatz:
Schicht
Was hier liegt
Wo es läuft
1. Öffentliche Marketing-Schicht
Leistungs- und Diagnoseseiten, Ärzteprofile, Standortseiten, Blog-Inhalte, allgemeine Kontaktformulare ohne Gesundheitsdetails
Nativ auf Webflow
2. Die Grenze zu Gesundheitsdaten
Der Punkt, an dem ein Formular, ein Chat-Widget oder ein Portal-Link beginnen würde, gesundheitsspezifische Informationen zu erfassen
Nirgendwo: Das ist eine Design-Entscheidung, kein Tool
3. Schicht der vertraglich abgesicherten Tools
Terminanfragen mit Gesundheitskontext, Anamnesebögen, Patientenportal-Zugang, sichere Nachrichten
Ein separater Drittanbieter mit geeignetem Auftragsverarbeitungsvertrag
Schicht 1: Was auf Webflow tatsächlich unbedenklich ist
Der Großteil des Inhalts einer Gesundheitswebsite liegt hier, ohne regulatorisches Risiko: Beschreibungen von Leistungen und behandelten Indikationen, Qualifikationen und Profile der Ärzte, Standort- und Öffnungszeiten, akzeptierte Krankenkassen, allgemeine Gesundheitsinhalte und Blogbeiträge, sowie ein einfaches Kontaktformular, das nur Name, Telefonnummer und E-Mail erfasst, ohne Symptom- oder Diagnosefeld. Strukturierte Daten vom Typ LocalBusiness, Physician oder MedicalOrganization passen hier natürlich hinein und helfen sowohl der klassischen Suche als auch KI-Antwortmaschinen, die Praxis korrekt zu verstehen und darzustellen.
Schicht 2: Die Grenze bewusst ziehen
Die Grenze zu Gesundheitsdaten ist keine Software, sondern eine Regel, auf die sich Ihr Team und Ihre Agentur einigen, bevor ein einziges Formularfeld gebaut wird: Nichts auf der Webflow-gehosteten Website erfasst oder übermittelt eine Information, die Identität mit Gesundheitskontext verbindet. In der Praxis bedeutet das, jedes Formularfeld der Website zu prüfen, nicht nur die offensichtliche Anamnese-Seite, und sich zu fragen, ob eine echte Antwort auf dieses Feld etwas Gesundheitsbezogenes über eine benannte Person verraten würde. Ein offenes Feld „Wie können wir helfen" scheitert an diesem Test fast immer, weil Patienten es nutzen werden, um Symptome zu beschreiben, unabhängig von der Feldbezeichnung.
Schicht 3: Wohin Gesundheitsdaten tatsächlich gehen
Alles, was die Grenze überschreitet, muss von einem Tool verarbeitet werden, das vertraglich abgesichert und von Grund auf für Gesundheitsdaten gebaut ist. Spezialisierte Plattformen wie Keragon für DSGVO-konforme Automatisierungen und Formular-zu-Akte-Workflows, oder dedizierte Formulartools für Gesundheitsdaten, lassen sich in Webflow integrieren, indem sie die eigentliche Datenerfassung und -verarbeitung selbst übernehmen, oft über ein eingebettetes Widget oder eine Weiterleitung auf eine separat gehostete, vertraglich abgesicherte Seite, während die umgebende Marketing-Website auf Webflow bleibt. Praxisverwaltungs- und Terminbuchungssysteme, die von den meisten Gesundheitsorganisationen bereits genutzt werden, funktionieren bereits so, und das sauberste Muster ist meist ein klar beschrifteter Button „Termin anfragen" oder „Patientenportal", der vollständig an dieses System übergibt, statt zu versuchen, diese Funktion in einem nativen Webflow-Formular nachzubauen.
So sieht das konkret bei einer Terminanfrage aus
Ein typisches Fehlermuster: Eine Praxis möchte, dass Besucher einen Termin anfragen und den Grund nennen können, also wird ein Webflow-Formular mit Name, E-Mail, Telefon und einem Feld „Anliegen" gebaut, das an das native Webflow-Formularbackend oder eine allgemeine E-Mail-Benachrichtigung übermittelt wird. Das ist ein Erfassungspunkt für Gesundheitsdaten über eine Infrastruktur ohne geeigneten Vertrag, in dem Moment, in dem jemand „Verlaufskontrolle nach Diagnose" in dieses Feld schreibt.
Auch die E-Mail-Benachrichtigung verdient eine eigene Erwähnung: Selbst wenn das Formular selbst irgendwie konform wäre, ist das Weiterleiten einer Einreichung mit Gesundheitskontext an das normale E-Mail-Postfach eines Mitarbeiters eine eigenständige Schwachstelle, da Standard-E-Mail nicht auf dem für solche Daten erforderlichen Niveau verschlüsselt ist, unabhängig davon, welches Formulartool die Nachricht erzeugt hat.
Die oben beschriebene Architektur lässt diesen Button statt dessen auf ein separates, vertraglich abgesichertes Terminbuchungs- oder Anamnese-Tool verlinken oder es einbetten, wo das Anliegen-Feld von einem Anbieter erfasst und gespeichert wird, der vertraglich und technisch dafür gebaut ist, inklusive sicherer interner Weiterleitung an das Personal statt einer Klartext-E-Mail. Die Aufgabe der Webflow-Website endet bei „so fragen Sie einen Termin an", nicht bei der Erfassung oder Übermittlung des eigentlichen Gesundheitskontexts.
Webflow im Vergleich zu anderen Plattformen bei Gesundheitsdaten
Das ist keine Webflow-spezifische Lücke, sondern eher der Normalfall für allgemeine Website-Baukästen, mit ein paar erwähnenswerten Ausnahmen, falls die Plattformwahl noch offen ist.
Webflow bietet derzeit keinen dieser beiden Wege an, weshalb die oben beschriebene mehrschichtige Architektur, statt einer Compliance-Funktion auf Plattformebene, der realistische Ansatz für ein Team ist, das Webflow gezielt wegen seiner Design- und Content-Workflow-Stärken einsetzen möchte.
Eine praktische Checkliste vor dem Launch
Vor dem Go-Live einer Gesundheitswebsite auf Webflow, direkt mit dem Team durchzugehen, das sie gebaut hat:
- Jedes Formular der Website wurde Feld für Feld nach dem oben beschriebenen Gesundheitsdaten-Test geprüft, nicht nur die offensichtlich gesundheitsbezogenen Seiten
- Jeder Termin-, Anamnese- oder Portalzugangspunkt übergibt an ein geeignetes Drittanbieter-Tool, statt über das native Webflow-Formularbackend zu laufen
- Analytics- und Werbe-Pixel sind bestätigt abwesend von allem hinter der Gesundheitsdaten-Grenze, und bestätigt so konfiguriert, dass sie auch auf der öffentlichen Marketing-Schicht keine Seitentitel, URLs oder Parameter mit Gesundheitskontext erfassen
- E-Mail-Benachrichtigungen zu jedem Formular, auch nicht gesundheitsbezogenen, wurden auf ihren tatsächlichen Inhalt geprüft
- Jemand, intern oder über die Agentur, verantwortet einen dokumentierten Prozess für Auskunfts-, Berichtigungs- oder Löschanfragen Betroffener
Gesundheitsspezifische Design-Überlegungen jenseits der Compliance
Compliance ist die Überlegung mit dem höchsten Risiko, aber nicht die einzige, die für das Gesundheitswesen spezifisch ist. Barrierefreiheit hat in diesem Sektor besonders direktes rechtliches und ethisches Gewicht, da die Zielgruppe, die nach einem Gesundheitsanbieter sucht, einen deutlich höheren Anteil an Besuchern mit visuellen, motorischen oder kognitiven Einschränkungen umfasst als der Durchschnitt kommerzieller Websites. Das Barrierefreiheitsstärkungsgesetz (BFSG) und die einschlägigen WCAG-Standards greifen hier direkt.
Vertrauenssignale zählen auf einer Gesundheitswebsite mehr als in fast jeder anderen Branche: sichtbare Qualifikationen der Ärzte, klare Informationen zu Kassenleistungen und Kosten, und echte Patientenergebnisse (sofern sie geteilt werden können, ohne selbst zu Gesundheitsdaten zu werden) leisten in einem Bereich, in dem der Besucher unter emotionalem Druck eine Entscheidung trifft, oft für die eigene Gesundheit oder die eines Angehörigen, echte Arbeit.
Is Webflow HIPAA compliant?
No, not on its own. Webflow doesn't offer a Business Associate Agreement, doesn't provide HIPAA-grade encryption for data at rest, and lacks the audit logging HIPAA requires. A healthcare organization can still use Webflow for its public marketing site as long as Protected Health Information is routed through a separate, BAA-covered tool rather than Webflow's native forms or CMS.
Can I use a Webflow form to collect patient information?
Not if that information qualifies as Protected Health Information, meaning identifying information combined with health context. A form collecting only a name and contact details for general inquiries is generally fine on Webflow natively. Anything asking about symptoms, conditions, or treatment should route through a separate HIPAA-compliant tool instead.
What's the difference between a HIPAA-compliant website builder and Webflow?
A small number of platforms, including Wix on certain plans, offer a built-in Business Associate Agreement and HIPAA-oriented infrastructure directly. Webflow doesn't currently offer this path, which means HIPAA compliance for a Webflow-built healthcare site has to be achieved architecturally, by keeping PHI off the platform entirely, rather than through a platform feature.
Do I need a BAA with my Webflow agency too?
Generally, only if that agency or its tools will directly handle PHI on your behalf, which a well-architected build specifically avoids. If your agency is only building the public marketing layer and PHI is handled entirely by a separate, dedicated tool, a BAA with the web agency typically isn't required, though this is exactly the kind of question worth confirming directly with a compliance attorney for your specific situation.
Is this guide legal advice?
No. This is general technical and architectural guidance based on how Webflow and HIPAA's BAA requirement function. Confirm your organization's specific compliance posture, including whether a BAA is required with any particular vendor, with a qualified healthcare compliance attorney before launch.
