Healthtech Software Entwicklung im DACH-Raum: DiGA, DSGVO, Swissmedic (2026)
Wie entwickelt man zertifizierungsfähige Healthtech-Software für den DACH-Markt? DiGA-Zulassung beim BfArM, Swissmedic in der Schweiz, DSGVO-Gesundheitsdaten und Architekturmuster für regulierte Medizinprodukte — ein technischer Leitfaden.
Der DACH-Markt ist für Healthtech-Gründer gleichzeitig der attraktivste und der anspruchsvollste in Europa. Deutschland hat mit dem DiGA-Verfahren ein weltweit einzigartiges Erstattungssystem für digitale Gesundheitsanwendungen geschaffen. Die Schweiz pflegt eines der strengsten Datenschutzregime für Gesundheitsdaten. Und in Österreich treffen DSGVO und spezifische Gesundheitsdatengesetze aufeinander. Wer für diesen Markt entwickelt, muss sowohl technisch als auch regulatorisch auf einem anderen Level arbeiten als bei Standard-SaaS-Produkten.
Dieser Leitfaden richtet sich an Healthtech-Gründer, Produkt-Owner und CTOs, die verstehen wollen, was Healthtech-Entwicklung im DACH-Kontext wirklich bedeutet — technisch, regulatorisch und finanziell.
DiGA: Digitale Gesundheitsanwendungen und der Weg zur Kassenleistung
Mit dem Digitale-Versorgung-Gesetz (DVG) von 2019 hat Deutschland ein weltweit einzigartiges Instrument geschaffen: die DiGA — eine App auf Rezept, die von der gesetzlichen Krankenversicherung erstattet wird. Für Healthtech-Unternehmen ist das eine enorme Chance: Zugang zu 73 Millionen GKV-Versicherten, Erstattungsbeträge zwischen €200 und €600 pro Verordnung, und ein standardisierter Zulassungsprozess mit 90 Tagen Bearbeitungszeit.
Die drei Zulassungskriterien des BfArM
Das Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) prüft DiGA-Anträge in einem Fast-Track-Verfahren anhand von drei Hauptkriterien:
1. Positiver Versorgungseffekt: Die DiGA muss entweder einen medizinischen Nutzen (klinischer Nachweis durch Studie) oder einen patientenrelevanten Struktur- und Verfahrenseffekt (z. B. bessere Therapietreue, vereinfachte Kommunikation) nachweisen. Für die vorläufige Aufnahme reicht ein plausibles Studienkonzept — der Nachweis muss innerhalb von 12 Monaten erbracht werden.
2. Datensicherheit: Das BfArM prüft gegen einen spezifischen Anforderungskatalog mit über 100 technischen und organisatorischen Controls. Kernanforderungen sind Verschlüsselung, sicheres Hosting in der EU, kein Tracking durch Drittanbieter-Werbenetze und robuste Authentifizierung.
3. Interoperabilität: DiGA müssen HL7 FHIR für den Datenaustausch mit anderen Gesundheitssystemen unterstützen — eine technische Anforderung, die in der Entwicklung von Anfang an berücksichtigt werden muss.
Technische Architektur für DiGA-fähige Apps
Die technischen Anforderungen des BfArM unterscheiden sich wesentlich von Standard-SaaS-Architektur. Wer ein DiGA-Produkt entwickelt, muss diese Anforderungen von Beginn an einplanen — nachträgliche Zertifizierungskorrekturen sind teuer.
Hosting und Datenlokalisierung
Alle Gesundheitsdaten müssen in Deutschland oder der EU gehostet werden. Viele DiGA-Hersteller wählen deutsche Rechenzentren (z. B. Hetzner, IONOS, OVH Deutschland) oder AWS eu-central-1 (Frankfurt). Multi-Cloud-Setups sind möglich, erfordern aber genaue Dokumentation der Datenflüsse im Zulassungsantrag.
Verschlüsselung und Datenschutzarchitektur
Das BfArM verlangt Ende-zu-Ende-Verschlüsselung für alle Gesundheitsdaten. Praktisch bedeutet das: Verschlüsselung at rest (AES-256) für alle Datenbankfelder mit Gesundheitsdaten, TLS 1.2+ für alle Übertragungen und — für höhere Risikoklassen — Verschlüsselung so, dass selbst der Betreiber keinen Klartextzugriff hat.
FHIR-Schnittstellen
HL7 FHIR (Fast Healthcare Interoperability Resources) ist der internationale Standard für den Austausch von Gesundheitsdaten. DiGA müssen FHIR-Exporte für patientenbezogene Daten anbieten. In der Praxis bedeutet das: Eine FHIR-API für den Datenexport und die Möglichkeit, Daten in Patientenakten (EPA in Deutschland, EPD in der Schweiz) zu übertragen.
Swissmedic und das Schweizer Healthtech-Marktumfeld
Die Schweiz hat ihr Medizinprodukterecht weitgehend an die EU-MDR (Medical Device Regulation) angeglichen. Swissmedic reguliert Medizinprodukte, darunter auch Software as a Medical Device (SaMD). Für Healthtech-Produkte, die in der Schweiz vertrieben werden sollen, gelten folgende Besonderheiten:
MDR-Klassifizierung und Schweizer Anpassungen
Software, die medizinische Diagnosen, Therapieempfehlungen oder klinische Entscheidungen unterstützt, fällt unter die MDR als SaMD. Die Risikoklassifizierung (I, IIa, IIb, III) bestimmt den Zertifizierungsaufwand. Klasse I (niedrigstes Risiko, z. B. reine Informationsanzeige) erfordert eine Selbsterklärung; ab Klasse IIa ist eine Benannte Stelle involviert.
Swissmedic akzeptiert für Klasse-I-Produkte EU-CE-Kennzeichnungen mit eingeschränkten Anforderungen. Ab Klasse IIa ist eine gesonderte Schweizer Zulassung mit eigenem Konformitätsbewertungsverfahren erforderlich — das schlägt mit €30.000–€80.000 zusätzlichem Aufwand zu Buche.
Das Schweizer Datenschutzgesetz (nDSG)
Das revidierte Schweizer Datenschutzgesetz, in Kraft seit September 2023, ist eng an die DSGVO angelehnt, hat aber Eigenheiten: Das Konzept der Datenschutz-Folgeabschätzung (in der Schweiz: Datenschutz-Folgenabschätzung) ist verpflichtend, die Strafrahmen unterscheiden sich, und Personendaten zu Gesundheit und Biometrie gelten als besonders schützenswert.
DSGVO für Gesundheitsdaten: Die kritischen Unterschiede
Gesundheitsdaten sind unter Art. 9 DSGVO besondere Kategorien personenbezogener Daten. Das bedeutet: Erhöhte Anforderungen an die Rechtsgrundlage, zwingend explizite Einwilligung (kein berechtigtes Interesse als Rechtsgrundlage), eine Datenschutz-Folgeabschätzung (DSFA) ist in fast allen Fällen Pflicht.
Österreichische DSGVO-Besonderheiten
Österreich hat im Rahmen der DSGVO-Öffnungsklauseln eigene Regelungen für Gesundheitsdaten implementiert. Das Gesundheitstelematikgesetz und das Krankenanstaltenrecht enthalten zusätzliche Vorgaben für digitale Gesundheitsanwendungen. Produkte, die in Österreich mit dem Gesundheitssystem interagieren (z. B. ELGA — Elektronische Gesundheitsakte), müssen zusätzliche Zertifizierungsanforderungen erfüllen.
Kostenübersicht: Healthtech-Entwicklung nach Produkttyp
| Produkttyp | Regulatorischer Pfad | Entwicklungskosten | Zulassungskosten | Gesamtinvestition |
|---|---|---|---|---|
| Wellness-App (kein Medizinprodukt) | DSGVO, kein MDR | €80.000–€150.000 | €0–€15.000 | €80.000–€165.000 |
| DiGA (Klasse I, einfach) | BfArM Fast-Track | €150.000–€250.000 | €50.000–€100.000 | €200.000–€350.000 |
| DiGA (Klasse IIa) | BfArM + Benannte Stelle | €200.000–€350.000 | €80.000–€150.000 | €280.000–€500.000 |
| SaMD für Schweizer Markt | MDR + Swissmedic | €180.000–€300.000 | €60.000–€120.000 | €240.000–€420.000 |
| B2B Klinik-Software (kein Medizinprodukt) | DSGVO, KHZG-fähig | €200.000–€400.000 | €20.000–€40.000 | €220.000–€440.000 |
Architekturmuster für regulierte Healthtech-Produkte
Aus der Praxis mehrerer Healthtech-Entwicklungsprojekte haben sich bestimmte Architekturmuster als besonders tauglich für regulierte Gesundheits-Software erwiesen.
Trennung von Gesundheitsdaten und Benutzerdaten
Eine strikte Trennung von Identitätsdaten (Name, E-Mail, Adresse) und Gesundheitsdaten (Symptome, Therapieverläufe, Messungen) in separaten Datenbankschemas — idealerweise in separaten Services — reduziert das Risiko von Datenpannen erheblich und vereinfacht die DSFA-Dokumentation. Gesundheitsdaten können mit einem eigenen Verschlüsselungsschlüssel (Customer Managed Key) geschützt werden, der unabhängig von den Systemschlüsseln rotiert werden kann.
Consent-Management als eigenständiger Service
DiGA-Patienten können ihre Einwilligung jederzeit widerrufen. Das muss technisch in Echtzeit wirksam werden: Keine weiteren Datenverarbeitungen, vollständiger Löschpfad. Ein Consent-Management-Service, der alle anderen Services über Einwilligungsänderungen informiert (via Event-Bus oder direkter API-Aufruf), ist die technisch sauberste Lösung.
Audit-Trail für Medizinprodukte
Für MDR-zertifizierte Produkte ist ein vollständiger Audit-Trail Pflicht: Alle klinisch relevanten Aktionen (Dateneingaben, Therapieempfehlungen, Nutzeraktionen) müssen mit Zeitstempel, Nutzer-ID und Kontext unveränderbar protokolliert werden. Unveränderlichkeit bedeutet technisch: Append-only-Logs, kryptographische Verkettung (ähnlich einer Blockchain) oder ein separates, schreibgeschütztes Log-System.
Warum Healthtech ein spezialisiertes Studio braucht
Die regulatorischen Anforderungen für Healthtech sind nicht Add-ons, die man am Ende einbaut — sie bestimmen die Architektur von Anfang an. Ein Studio, das DiGA-Anforderungen kennt, entwirft die Datenbankstruktur anders, wählt andere Hosting-Anbieter, implementiert andere Logging-Mechanismen.
Zulbera arbeitet mit Healthtech-Gründern zusammen, die regulationsfähige Produkte für den DACH-Markt aufbauen wollen. Unsere Erfahrung mit DSGVO-konformer Architektur, regulierten Datenflüssen und sicheren Infrastrukturkonzepten kommt Healthtech-Projekten direkt zugute. Mehr zu unserer Arbeit auf der Seite SaaS-Entwicklung oder unserer Übersicht zu Enterprise-Webanwendungen.
Checkliste: Technische DiGA-Vorbereitung
- Hosting in Deutschland oder EU — zertifizierter Rechenzentrumsanbieter
- Verschlüsselung at rest und in transit für alle Gesundheitsdaten
- Kein Third-Party-Tracking (Analytics, Werbenetze) für Gesundheitsdaten
- Zwei-Faktor-Authentifizierung für Nutzer implementiert
- FHIR-Export für patientenbezogene Daten
- Löschpfad für Nutzerdaten vollständig implementiert und getestet
- Consent-Management mit Widerrufsfunktion
- Penetrationstest durch akkreditierten Tester (BSI-zertifiziert)
- Technische Dokumentation nach MDR Annex II vorbereitet
- ISMS eingeführt (ISO 27001 oder BSI IT-Grundschutz)
Fazit
Healthtech im DACH-Markt ist komplex — regulatorisch, technisch und organisatorisch. Aber die Chancen sind enorm: Ein erfolgreich zugelassenes DiGA-Produkt hat Zugang zu einem der kaufkräftigsten Gesundheitsmärkte weltweit, mit standardisierten Erstattungspfaden und einer hohen Zahlungsbereitschaft.
Der Schlüssel zum Erfolg liegt in der frühen Verzahnung von Entwicklung und Regulatory Affairs. Studios und Berater, die beide Seiten verstehen, sind selten — aber entscheidend für den Projekterfolg.
Wenn Sie eine DiGA-fähige App oder regulierte Healthtech-Software für den DACH-Markt entwickeln wollen, sprechen Sie mit Zulbera. Wir bringen die technische Tiefe mit, die regulierte Produkte erfordern.
Häufig gestellte Fragen
Was ist eine DiGA und wie funktioniert die BfArM-Zulassung?
Eine DiGA ist eine App auf Rezept, die von der GKV erstattet wird. Das BfArM prüft in 90 Tagen Versorgungseffekt, Datensicherheit und Interoperabilität. Vorläufige Aufnahme ist ohne abgeschlossene Studie möglich — diese muss innerhalb von 12 Monaten nachgeliefert werden.
Welche Datensicherheitsanforderungen gelten für DiGA?
Ende-zu-Ende-Verschlüsselung, EU-Hosting, kein Drittanbieter-Tracking, Zwei-Faktor-Authentifizierung, jährliche Penetrationstests und ein zertifiziertes ISMS (ISO 27001 oder BSI IT-Grundschutz).
Was kostet die Entwicklung einer DiGA-fähigen App?
Die Gesamtinvestition bis zur vorläufigen DiGA-Aufnahme liegt typischerweise bei €200.000–€500.000 inklusive Entwicklung, Regulatory-Affairs-Beratung und Zulassungsgebühren.
Was sind die Unterschiede zwischen BfArM und Swissmedic?
Das BfArM verwaltet das weltweit einzigartige DiGA-Erstattungssystem. Swissmedic folgt der EU-MDR und erfordert ab Klasse IIa eine eigenständige Schweizer Zulassung — zusätzlich zur EU-CE-Kennzeichnung.
Wie lange dauert Entwicklung und DiGA-Zulassung insgesamt?
Realistisch 14–22 Monate: 8–12 Monate Entwicklung und Dokumentation, 3 Monate BfArM-Prüfung, 2–4 Monate Puffer für Nachforderungen.