Healthtech-Softwareentwicklung für den deutschen Markt: DiGA, gematik, FHIR und Hosting
Deutschland hat 83 Millionen Einwohner, eine gesetzliche Krankenversicherung, die fast alle abdeckt, und ein Gesundheitssystem, das erst seit Kurzem für Software bezahlt. Diese Kombination macht es zu einem der attraktivsten Digital-Health-Märkte Europas, und zu einem der schwierigsten für den Einstieg. Healthtech-Softwareentwicklung für Deutschland bedeutet, gegen einen Stapel von Regeln zu bauen, den die meisten anderen Märkte nicht haben: einen Erstattungsweg für Apps mit eigener Zertifizierung, ein nationales Gesundheitsnetz, das von einer einzigen Agentur betrieben wird, und ein Datenschutzrecht, das einen Diagnosecode anders behandelt als eine E-Mail-Adresse.
Dieser Beitrag richtet sich an Gründer und CTOs, die ein Produkt für den deutschen Markt planen oder bereits eines haben und gerade erfahren, was der Einkauf des nächsten Kunden verlangen wird. Wir haben zuvor über Compliance für Healthcare-SaaS in Europa und über Engineering für den Europäischen Gesundheitsdatenraum geschrieben. Dieser Beitrag bleibt innerhalb Deutschlands und geht bei den Teilen in die Tiefe, die hier spezifisch sind.
Der regulatorische Rahmen: DiGA, MDR und gematik
Drei regulatorische Ebenen prägen die meisten Healthtech-Produkte in Deutschland. Welche davon gelten, hängt davon ab, was Ihre Software tut und wer dafür bezahlt.
Die erste ist die Einstufung als Medizinprodukt nach der EU-Medizinprodukteverordnung (MDR). Wenn Ihre Software Diagnose, Therapie oder Überwachung eines Patienten unterstützt, ist sie sehr wahrscheinlich ein Medizinprodukt, und die MDR-Regel für Software (Regel 11) schiebt sie tendenziell in Klasse IIa oder höher statt in Klasse I. Diese Entscheidung fällt früh, und sie falsch zu treffen ist teuer. Ein Produkt der Klasse I kann selbst erklärt werden; alles darüber braucht eine Benannte Stelle, ein Qualitätsmanagementsystem nach ISO 13485 und eine technische Dokumentation, zu der Entwickler über die gesamte Lebensdauer des Produkts beitragen. Eine Wellness-App, die den Schlaf erfasst, ist kein Medizinprodukt. Eine App, die einem Diabetiker sagt, wie viel Insulin er nehmen soll, schon.
Die zweite Ebene ist die DiGA, der 2019 mit dem Digitale-Versorgung-Gesetz eingeführte Erstattungsweg. Eine DiGA ist ein Medizinprodukt niedriger Risikoklasse (I oder IIa), das ein Arzt verschreiben kann und das die gesetzliche Krankenversicherung bezahlt. Die Zulassung läuft über das Fast-Track-Verfahren beim BfArM und verlangt mehr als ein funktionierendes Produkt: den Nachweis eines positiven Versorgungseffekts, entweder vorab oder innerhalb einer vorläufigen Listung, plus den Nachweis, dass die Software die Anforderungen der DiGA-Verordnung an Datenschutz, Informationssicherheit, Interoperabilität und Nutzerfreundlichkeit erfüllt. Seit 2025 gehört zu den Sicherheitsanforderungen ein zertifiziertes Informationssicherheits-Managementsystem nach ISO 27001, was bedeutet, dass ein junges Unternehmen ein ISMS braucht, bevor es nennenswerten Umsatz hat. Planen Sie das ein.
Die dritte Ebene ist die gematik, die Agentur, die die Telematikinfrastruktur (TI) betreibt, Deutschlands nationales Gesundheitsdatennetz. Wenn Ihr Produkt mit Praxisverwaltungssystemen sprechen, elektronische Rezepte empfangen, Dokumente über KIM (den Maildienst der TI) mit Ärzten austauschen oder aus der elektronischen Patientenakte lesen und in sie schreiben soll (die ePA ist 2025 auf ein Opt-out-Modell umgestellt worden), haben Sie es mit gematik-Spezifikationen zu tun. Praxissoftware hat ein eigenes Zulassungsverfahren bei der gematik. Die meisten Healthtech-Startups bauen kein Praxissystem, aber viele brauchen eine TI-Anbindung, und die Spezifikationen sind lang, versioniert und auf Deutsch geschrieben.
Keine dieser Ebenen ist optional, wenn sie auf Sie zutrifft, und die Reihenfolge ist wichtig. Klären Sie zuerst die MDR-Klasse, denn sie bestimmt, ob DiGA überhaupt in Frage kommt und wie viel Ihres Prozesses dokumentiert werden muss. Entscheiden Sie dann, ob Sie TI-Zugang brauchen, denn das verändert Ihre Hosting- und Sicherheitsarchitektur.
Datenstandards, die Sie sprechen müssen
Deutsche Gesundheitsdaten haben ein definiertes Vokabular, und Integrationen scheitern, wenn ein Produkt es ignoriert.
HL7 FHIR R4 ist das Austauschformat, auf das sich das deutsche System festgelegt hat. Die ePA, der E-Rezept-Dienst und die ISiK-Spezifikationen für Krankenhausinformationssysteme basieren alle auf FHIR, und die gematik veröffentlicht deutsche Profile, die die Basisressourcen einschränken. Bauen Sie Ihr internes Datenmodell so, dass Patient, Encounter, Observation, Condition und MedicationRequest ohne eine Übersetzungsschicht, die Informationen verliert, auf FHIR-Ressourcen abgebildet werden. Sie müssen FHIR-JSON nicht nativ speichern, aber wenn Ihr relationales Modell ein FHIR-Bundle nicht verlustfrei hin und zurück abbilden kann, wird spätere Integrationsarbeit zum Neubau.
Für die Kodierung nutzt Deutschland ICD-10-GM für Diagnosen, eine nationale Modifikation, die vom BfArM gepflegt und jedes Jahr aktualisiert wird. Sie unterscheidet sich von der WHO-Version und vom in den USA genutzten ICD-10-CM, eine importierte Codeliste aus einem US-Produkt ist für Deutschland also falsch. Prozeduren nutzen den OPS, ebenfalls ein deutsches System. SNOMED CT ist in Deutschland seit 2021 über eine nationale Lizenz verfügbar und in mehreren TI-Spezifikationen vorgeschrieben. LOINC deckt Laborergebnisse ab. Behandeln Sie all das als versionierte Referenzdaten mit einem Update-Prozess, nicht als Konstanten im Code. Ein Diagnosecode, der im Katalog 2025 gültig war, kann im Katalog 2026 aufgeteilt oder gestrichen sein, und Ihre Auswertungen müssen das überstehen.
Gesundheitsdaten unter der DSGVO in Deutschland
Gesundheitsdaten sind eine besondere Kategorie nach Artikel 9 der DSGVO. Das ändert, was standardmäßig erlaubt ist, und das Bundesdatenschutzgesetz ergänzt in § 22 eigene Regelungen für die Verarbeitung von Gesundheitsdaten im Behandlungskontext. Praktisch heißt das: Sie brauchen für jeden Verarbeitungszweck eine ausdrückliche Rechtsgrundlage, eine Datenschutz-Folgenabschätzung vor dem Launch und einen Datenschutzbeauftragten, wenn Sie Gesundheitsdaten in großem Umfang verarbeiten. "Wir haben eine Datenschutzerklärung" reicht nicht. Durchgesetzt wird das von den Aufsichtsbehörden der Bundesländer, nicht von einer nationalen Stelle, und sie prüfen Healthtech-Unternehmen tatsächlich.
Aufbewahrungspflichten ziehen in die entgegengesetzte Richtung wie das Recht auf Löschung. Nach § 630f BGB muss ein Arzt Behandlungsunterlagen zehn Jahre nach Abschluss der Behandlung aufbewahren, und andere Vorschriften verlängern das für manche Unterlagen auf dreißig Jahre. Wenn Ihr Produkt Dokumentation im Auftrag einer Klinik hält, können Sie die Daten eines Patienten auf Anfrage nicht einfach löschen. Sie müssen gesetzlich vorgeschriebene Aufbewahrung von Daten unterscheiden können, die Sie für eigene Zwecke halten, und nur letztere löschen. Die technische Seite davon haben wir in Engineering für das Recht auf Löschung nach DSGVO behandelt; im Gesundheitswesen sind die Aufbewahrungsausnahmen die Regel, nicht der Sonderfall.
Eine weitere deutsche Besonderheit: die ärztliche Schweigepflicht nach § 203 StGB. Ein Arzt, der einem Außenstehenden Zugriff auf Patientendaten gewährt, kann sich strafbar machen, es sei denn, dieser ist derselben Pflicht unterworfen. Seit 2017 können IT-Dienstleister als "mitwirkende Personen" verpflichtet werden, aber Ihre Verträge mit medizinischen Kunden müssen das festhalten, und Ihre Mitarbeiter müssen wissen, dass diese Pflicht existiert.
Hosting-Anforderungen
Wo die Daten liegen, ist die Frage, die deutsche Käufer zuerst stellen. Die DiGA-Verordnung verlangt, dass personenbezogene Daten in Deutschland, einem anderen EU- oder EWR-Mitgliedstaat oder einem Land mit Angemessenheitsbeschluss verarbeitet werden, und nur für die Zwecke, die die Verordnung nennt. Krankenhäuser und Krankenkassen gehen oft weiter und verlangen ein Rechenzentrum in Deutschland. Die Frankfurter Region eines US-Hyperscalers erfüllt den Wortlaut der Verordnung, aber nicht jeden Einkauf; einige bestehen auf einem deutschen Anbieter oder einem Sovereign-Cloud-Angebot mit getrenntem Betrieb.
Die Zertifizierungen, die zur Sprache kommen, sind ISO 27001 für das ISMS und BSI C5, der deutsche Kriterienkatalog für Cloud-Sicherheit, für den Hosting-Anbieter. Seit 2024 brauchen Anbieter von Cloud-Diensten für die gesetzliche Krankenversicherung eine C5-Testierung nach § 393 SGB V. Wählen Sie einen Anbieter, der bereits eine hat; selbst einen C5-Bericht zu erlangen ist ein eigenes Projekt. Auf Anwendungsseite definiert die Technische Richtlinie TR-03161 des BSI Sicherheitsanforderungen für Gesundheits-Apps, und DiGA-Antragsteller müssen die Einhaltung nachweisen.
Behandeln Sie das nicht als Papierkram. Es diktiert konkrete Entscheidungen: Verschlüsselung im Ruhezustand mit kundenkontrollierten Schlüsseln, Netzwerkisolation pro Umgebung, protokollierter und geprüfter Admin-Zugriff, getestete Backups mit definierten Wiederherstellungszeiten und keine Produktionsdaten in Staging. Wenn Sie das zur Architekturzeit einplanen, sind es ein paar Wochen Arbeit. Wenn Sie es nachrüsten, nachdem der Sicherheitsfragebogen eines Kunden eingetroffen ist, sind es Monate.
Architekturentscheidungen, die wir für Healthtech-SaaS treffen
Regulierung ist der Grund für die meisten strukturellen Entscheidungen in einem deutschen Healthtech-Produkt. So gehen wir bei Wolf-Tech typischerweise vor, wenn wir für diesen Markt individuelle Software entwickeln.
Die Mandantentrennung für Arztpraxen ist strenger als in einem normalen B2B-SaaS. Jede Praxis ist ein eigener Verantwortlicher mit eigener Schweigepflicht, geteilte Tabellen mit Mandantenspalte und Filterung auf Anwendungsebene sind dem Datenschutzbeauftragten einer Praxis also schwer zu verkaufen. Wir nutzen PostgreSQL Row-Level Security als Untergrenze und für größere Kunden ein Schema oder eine Datenbank pro Mandant, mit den Abwägungen, die wir in unserem Beitrag zu Row-Level Security beschrieben haben. Die Kosten sind operativ, vor allem bei Migrationen und Monitoring. Der Vorteil: Sie können die Frage "Kann Praxis A jemals die Daten von Praxis B sehen?" mit einer Datenbankgarantie beantworten statt mit einem Code-Review.
Aufsichtsbehörden verlangen Audit-Trails, also bauen wir sie von Anfang an ein. Die MDR erwartet Nachvollziehbarkeit, wer was an den Daten eines Produkts geändert hat, und die DSGVO verlangt, dass Sie rechtmäßigen Zugriff nachweisen können. Wir protokollieren jeden Lese- und Schreibzugriff auf Patientendaten mit Nutzer, Rolle, Zeitstempel, Zweck und Datensatzkennung in einem Append-only-Speicher, den Anwendungscode weder ändern noch löschen kann. Das Design haben wir in Audit-Log-Architektur für B2B-SaaS beschrieben. Im Gesundheitswesen gehört der Zugriff auf das Audit-Log selbst mit auf die Liste der protokollierten Ereignisse, denn die Frage "Wer hat in die Akte dieses Patienten geschaut?" stellen Aufsichtsbehörden und Patienten gleichermaßen.
API-Grenzen sind die Stellen, an denen Gesundheitsdaten in der Praxis abfließen, also halten wir sie schmal. Jede externe Schnittstelle, ob FHIR-Endpunkt, KIM-Gateway oder Laborimport, läuft über einen dedizierten Integrationsdienst mit eigenen Zugangsdaten, strikter Schema-Validierung und Rate Limits. Interne Dienste rufen externe Systeme nie direkt auf. Tokens für TI-Komponenten liegen in einem Secrets Manager mit Rotation, nie in Umgebungsdateien, die in ein Repository eingecheckt sind. Fehler externer Systeme werden ohne Payload protokolliert, denn ein Stacktrace mit einem FHIR-Bundle darin ist eine Datenpanne.
Schließlich versionieren wir die Referenzdaten. ICD-10-GM, OPS und die FHIR-Profile der gematik ändern sich alle jährlich, und die Software muss wissen, gegen welche Version ein Datensatz kodiert wurde. Eine kleine Tabelle mit Katalogversionen und Gültigkeitsdaten, in jedes kodierte Feld hineingejoint, erspart viel Verwirrung, wenn ein Bericht aus 2027 eine 2025 erfasste Diagnose erklären muss.
Wo Sie anfangen sollten
Wenn Sie früh dran sind, lautet die Reihenfolge: MDR-Klassifizierung mit einem Regulatory-Berater klären, entscheiden, ob DiGA Ihr Weg zum Umsatz ist, und erst dann die technische Architektur festlegen. Wenn Sie bereits ein Produkt haben und ein deutscher Kunde Fragen stellt, ist der schnellste Weg, herauszufinden, wo Sie stehen, ein strukturiertes Review von Codebasis und Infrastruktur gegen die oben genannten Anforderungen, und genau dafür ist unser Code Quality Consulting gedacht. So oder so: Die Unternehmen, die in diesem Markt erfolgreich sind, behandeln die Regulierung als Input für das Design, nicht als Checkliste am Ende.
Wenn Sie ein Healthtech-Produkt für Deutschland planen und eine zweite Meinung zur Architektur möchten, schreiben Sie uns an hello@wolf-tech.io oder besuchen Sie wolf-tech.io.