Apps und Backends für Gesundheit, Prävention und Versorgung – gebaut in Flutter, Go und .NET, gehostet in der EU. Vor der ersten Zeile Code klären wir gemeinsam, ob deine App unter die EU-Medizinprodukteverordnung fällt. An dieser Frage hängt ein erheblicher Teil des Aufwands.
Karim Belkacem · Regensburg · 0941 46395983 · info@sb-techworks.de
An dieser Weiche entscheidet sich ein erheblicher Teil des Projektaufwands – und sie wird oft zu spät gestellt. Maßgeblich ist die Zweckbestimmung: das, wofür du die App laut deinen eigenen Angaben anbietest (Art. 2 Nr. 12 der EU-Medizinprodukteverordnung, kurz MDR). Nicht die Technik entscheidet, sondern der erklärte Zweck.
Fitness, Ernährung, Schlaf, Achtsamkeit, allgemeines Wohlbefinden – solange die App keiner bestimmten Krankheit vorbeugen und sie weder erkennen noch behandeln soll. Dann greift die MDR nicht. Es bleiben Datenschutz und die Regeln von Apple und Google, die für Gesundheitsdaten eigene Einwilligungen verlangen und deren Nutzung für Werbung verbieten.
Sobald die App zur Diagnose, Verhütung, Überwachung, Vorhersage oder Behandlung einer Krankheit bestimmt ist, greift die MDR. Dann kommen Konformitätsbewertung – der formale Nachweis, dass das Produkt die Anforderungen erfüllt –, technische Dokumentation, Risikomanagement und ein Qualitätsmanagementsystem dazu. Je nach Klasse prüft eine Benannte Stelle mit, also eine unabhängige, staatlich benannte Prüforganisation.
Eine kleine Teilmenge der Medizinprodukte, verschreibungsfähig und von der Kasse erstattet. Voraussetzung ist die Aufnahme in das Verzeichnis des BfArM, der Nachweis eines positiven Versorgungseffekts und zwei Zertifikate – zu Datensicherheit und Datenschutz. Der Weg ist lang; die Zahlen dazu stehen weiter unten.
Vorsicht bei Prävention. „Verhütung“ von Krankheiten ist nach Art. 2 Nr. 1 MDR ausdrücklich ein medizinischer Zweck. Eine App, die einer bestimmten Krankheit vorbeugen soll – Sturzprävention, Diabetesprävention, Rückfallprophylaxe –, kann trotz des Etiketts „Prävention“ im regulierten Bereich landen. Allgemeine Gesundheitsförderung ohne Krankheitsbezug dagegen nicht.
Und ein Detail, das teuer werden kann: Zur Zweckbestimmung zählen nicht nur Handbuch und Oberfläche, sondern auch deine Werbematerialien. Wer auf der eigenen Website „erkennt Herzrhythmusstörungen“ schreibt, hat damit unter Umständen selbst ein Medizinprodukt erklärt – auch wenn die App technisch dasselbe tut wie vorher.
Die Einordnung selbst nehmen wir nicht vor – sie ist eine rechtliche Bewertung deines Einzelfalls und gehört zu deiner Rechts- oder QM-Beratung. Was wir tun, ist die technische Vorarbeit – Zweckbestimmung, Funktionsumfang und Datenflüsse so aufbereiten, dass diese Entscheidung auf einer belastbaren Grundlage getroffen werden kann. Die CE-Verantwortung liegt beim Hersteller, also bei dir.
Nicht jede Gesundheits-App braucht ein Zulassungsverfahren. Fällt deine App nicht unter die MDR, ist es ein normales App-Projekt – mit einem Datenschutzkapitel, das ernster ist als anderswo.
Der Ablauf entspricht dann unseren übrigen App-Projekten: Konzept und Architektur, eine Flutter-Codebasis für iOS und Android, ein Backend in Go oder .NET, Store-Launch. Ein MVP ist typischerweise in sechs bis zehn Wochen testbar, eine vollständige App in vier bis sechs Monaten – die Spannen aus der Preistabelle unten gelten dafür unverändert.
Der Unterschied liegt im Umgang mit den Daten. Vitalwerte, Schlaf, Zyklus, Medikation: Das sind Gesundheitsdaten im Sinne von Art. 9 DSGVO, auch ohne Medizinprodukt-Status. Getrennte Einwilligungen je Zweck, EU-Hosting und ein durchdachtes Löschkonzept sind hier keine Kür, sondern die Voraussetzung dafür, dass die App überhaupt in den Store kommt.
Und falls du später doch in den regulierten Bereich willst: Eine saubere Trennung von Datenhaltung, Auswertungslogik und Oberfläche macht diesen Schritt möglich, ohne von vorn anzufangen. Das kostet am Anfang wenig und spart später viel.
Vier Bausteine, die in Gesundheits-Projekten regelmäßig gebraucht werden – unabhängig davon, ob am Ende ein reguliertes Produkt steht.
Eine Flutter-Codebasis für beide Plattformen. Barrierefreie Oberflächen, Offline-Fähigkeit und ein Onboarding, das auch ohne Anleitung funktioniert – bei Gesundheitsthemen keine Kür.
APIs in Go, .NET oder Node.js, Datenmodell, Rollen und Rechte, Audit-Trail. Wenn es später Richtung FHIR oder Praxissoftware geht, entscheidet sich das an der Schnittstellenschicht.
Apple HealthKit, Google Health Connect, Garmin. Die Garmin-Anbindung haben wir in unserer eigenen Fitness-App Klaimo gebaut – Aktivitätsdaten nach Kontoverknüpfung über die Garmin-API.
Hosting in der EU, getrennte Einwilligungen je Zweck, Verschlüsselung, nachvollziehbare Löschkonzepte. Ob Health-Daten auf dem Gerät oder im Backend liegen, entscheidet sich hier – das später zu drehen heißt Datenmigration.
Wir haben bisher kein Medizinprodukt umgesetzt, keine DiGA entwickelt und keine Zertifizierung nach ISO 13485. Auch eine Gesundheits-App für einen Kunden war noch nicht dabei. Das steht hier, weil du es vor dem Gespräch wissen sollst und nicht danach.
Was wir haben: über 500.000 Downloads über alle Apps, Flutter-Apps für iOS und Android, Backends in Go und .NET im produktiven Betrieb – und mit Klaimo eine eigene Fitness-App, die Aktivitätsdaten aus der Garmin-API verarbeitet und Geodaten in Echtzeit auswertet. Das ist die technische Hälfte des Problems, nicht die regulatorische.
Für ein Projekt mit Medizinprodukte-Charakter heißt das konkret: Wir bauen die Software und die Dokumentation, die aus der Entwicklung entsteht. Qualitätsmanagementsystem, klinische Bewertung und Konformitätsbewertung laufen über eine spezialisierte Beratung, die du mitbringst oder gemeinsam mit uns auswählst. Wir trennen das bewusst – die Software bauen wir, die Zulassung gehört in spezialisierte Hände.
Wenn dein Projekt zwingend einen Entwickler mit eigener DiGA-Historie braucht, sagen wir dir das im Erstgespräch und nennen dir Häuser, die das können.
Die „App auf Rezept“ ist das am häufigsten genannte Ziel in Erstgesprächen. Ein paar Zahlen, bevor du darauf hinplanst.
Der Markt ist klein. Zum 31.12.2025 waren 58 DiGA gelistet – 48 dauerhaft, 10 vorläufig zur Erprobung. Das ist die Zahl aus dem dritten DiGA-Report des Spitzenverbands Digitale Gesundheitsversorgung vom März 2026, fünf Jahre nach dem Start.
Der Nutzennachweis ist die Hürde, nicht die Software. Nach dem DiGA-Bericht des GKV-Spitzenverbandes (Stand 31.12.2025) konnten von 74 aufgenommenen Anwendungen nur 14 – rund jede fünfte – den Nutzen bereits bei Aufnahme belegen. Weitere 34 haben ihn in der Erprobung nachgeholt, 16 wurden wieder gestrichen. Unterm Strich schafft rund zwei Drittel den Nachweis, aber die wenigsten sofort. Wer eine DiGA plant, plant eine Studie und nicht nur eine App.
Die Erprobungsphase ist kürzer, als sie klingt. Nach § 139e Abs. 4 SGB V läuft die vorläufige Aufnahme bis zu zwölf Monate. Eine Verlängerung um bis zu zwölf weitere ist möglich, aber kein Automatismus: Das BfArM kann sie nur gewähren, wenn die zum Ende der Erprobung vorgelegten Ergebnisse eine überwiegende Wahrscheinlichkeit einer späteren Nachweisführung zeigen. Und der Verlängerungszeitraum schließt die dreimonatige Entscheidungsfrist des BfArM ein – zusätzlich erhoben wird also weniger lang, als die Zahl vermuten lässt.
Zwei Zertifikate, nicht eines. Für DiGA verlangt das BfArM einen Nachweis zur Datensicherheit nach der Technischen Richtlinie BSI TR-03161 (§ 139e Abs. 10 SGB V, Pflicht seit 01.01.2025) und zusätzlich ein Datenschutz-Zertifikat nach Art. 42 DSGVO auf Basis der BfArM-Prüfkriterien (§ 139e Abs. 11 SGB V, Pflicht seit 01.08.2024). Beide betreffen genau die Ebenen, auf denen wir arbeiten: App, Backend und die Schnittstellen dazwischen. Ausgestellt werden sie von einer Prüfstelle, nicht von uns.
Und der Erlös steht nicht fest. Seit dem 01.01.2026 muss die Vergütungsvereinbarung nach § 134 Abs. 1 SGB V erfolgsabhängige Preisbestandteile von mindestens 20 Prozent vorsehen. Business-Cases, die mit einem festen Betrag je Freischaltcode rechnen, sind damit überholt.
Nichts davon soll abschrecken. Es soll nur an der richtigen Stelle stehen: vor dem Angebot. Für viele Ideen, die als DiGA gedacht waren, ist der schnellere Weg eine App ohne Zulassung – und die kann den regulierten Weg später immer noch gehen. Ausführlicher steht das im Leitfaden zur Gesundheits-App-Entwicklung.
Art. 9 Abs. 1 DSGVO untersagt die Verarbeitung von Gesundheitsdaten grundsätzlich. Erlaubt ist sie bei Apps praktisch nur mit ausdrücklicher Einwilligung nach Art. 9 Abs. 2 lit. a – und die muss freiwillig, informiert und je Zweck getrennt sein. Ein einziges Häkchen „Ich stimme der Verarbeitung meiner Daten zu“ reicht dafür nicht.
Für DiGA kommt eine Vorgabe dazu, die direkt in die Architektur greift: Nach § 4 Abs. 3 DiGAV dürfen personenbezogene Daten nur im Inland, in EU-Mitgliedstaaten, in gleichgestellten Staaten oder in Drittstaaten mit Angemessenheitsbeschluss verarbeitet werden. Das betrifft nicht nur den Hauptserver, sondern die ganze Kette: Auftragsverarbeiter, Backup-Regionen, Fehler-Tracking, Monitoring, Push-Dienste, CDN. Diese Kette sehen wir uns früh an, weil sie sich später nur teuer umbauen lässt.
Zweckbestimmung und Datenflüsse aufbereiten, damit du die Medizinprodukt-Frage mit deiner Rechts- oder QM-Beratung entscheiden kannst. Ergebnis: eine schriftliche Architektur- und Budgetskizze – kostenlos.
Datenmodell, Hosting-Regionen, Einwilligungskonzept und Schnittstellen. Hier fällt zum Beispiel, ob Health-Daten auf dem Gerät oder im Backend liegen.
App und Backend in klaren Meilensteinen. Nach jedem Schritt eine lauffähige Version, die du selbst ausprobierst – nicht nur ein Statusbericht.
Store-Veröffentlichung, Übergabe mit vollständigem Quellcode und Dokumentation. Auf Wunsch Wartung und Weiterentwicklung.
Drei Spannen als Orientierung. Dein konkreter Kostenrahmen steht vor Projektstart fest, nicht danach.
Alle Preise zzgl. gesetzlicher Umsatzsteuer. Die Spannen für MVP und Gesundheits-App sind Erfahrungswerte aus unseren App- und Backend-Projekten außerhalb des regulierten Bereichs; der Wert für regulierte Projekte ist eine Kalkulationsschätzung, kein Erfahrungswert. Grundlage des Festpreises ist der im Erstgespräch abgestimmte Leistungsumfang. Zulassungskosten – Prüfstelle, Benannte Stelle, klinische Bewertung – sind nicht enthalten und laufen nicht über uns.
Das hängt an der Zweckbestimmung – dem, wofür du die App laut deinen eigenen Angaben anbietest (Art. 2 Nr. 12 MDR). Dient sie der Diagnose, Verhütung, Überwachung, Vorhersage oder Behandlung einer Krankheit, ist sie in der Regel ein Medizinprodukt. Achtung bei Prävention: „Verhütung“ ist nach Art. 2 Nr. 1 MDR ausdrücklich ein medizinischer Zweck. Auch deine Werbetexte zählen zur Zweckbestimmung. Die Einordnung selbst ist eine rechtliche Bewertung und gehört zu deiner Rechts- oder QM-Beratung; wir bereiten sie technisch vor.
Dann ist es ein normales App-Projekt: Flutter für iOS und Android, ein Backend, Store-Launch. MVP in 6–10 Wochen, vollständige App in 4–6 Monaten. Der Unterschied zu anderen Apps liegt beim Datenschutz – Vitalwerte und Schlafdaten sind Gesundheitsdaten nach Art. 9 DSGVO, auch ohne Medizinprodukt-Status. Und Apple wie Google prüfen Health-Apps im Store genauer.
Ein MVP mit klarem Funktionskern liegt bei 2.700–6.000 €, eine vollständige App für iOS und Android mit Backend und Wearable-Anbindung bei 7.000–13.000 €, jeweils zzgl. USt. Projekte mit Medizinprodukte-Charakter starten ab 20.000 € – das ist eine Kalkulationsschätzung, kein Erfahrungswert, weil wir noch kein reguliertes Projekt umgesetzt haben. Zulassungskosten sind nicht enthalten. Wenn der Leistungsumfang nach dem Erstgespräch klar ist, bekommst du ein Festpreisangebot; bei regulierten Vorhaben zunächst ein Angebot für eine kostenpflichtige Konzeptphase.
Nein. Wir haben bisher kein Medizinprodukt umgesetzt, keine DiGA entwickelt und keine ISO-13485-Zertifizierung. Was wir haben: Flutter-Apps mit über 500.000 Downloads, Backends in Go und .NET im produktiven Betrieb und mit Klaimo eine eigene Fitness-App, die Garmin-Daten verarbeitet. Für ein reguliertes Projekt bauen wir die Software und die Dokumentation aus der Entwicklung; Qualitätsmanagement und Konformitätsbewertung laufen über eine spezialisierte Beratung. Wenn dein Vorhaben zwingend einen Entwickler mit DiGA-Historie braucht, sagen wir dir das.
Dann hilft es, wenn die Architektur das von Anfang an offenhält: Datenhaltung, Auswertungslogik und Oberfläche sauber getrennt, Änderungen nachvollziehbar dokumentiert, Hosting schon in der EU. Das kostet am Anfang wenig zusätzlichen Aufwand und erspart später einen Neubau. Die Zulassung selbst beginnt trotzdem von vorn – aber nicht die Software.
Ja. Beide Plattformen liefern Vitalwerte, Aktivität und Schlafdaten, sobald Nutzerinnen und Nutzer zustimmen. Beide haben eigene Regeln: Health-Daten dürfen nicht für Werbung genutzt werden, und die Store-Prüfung schaut bei Gesundheitsthemen genauer hin. Die Garmin-Anbindung über deren API haben wir in unserer eigenen App Klaimo umgesetzt.
Wir melden uns Mo–Fr innerhalb von 24 Stunden mit einer ehrlichen Einschätzung – inklusive der Frage, ob dein Vorhaben überhaupt in den regulierten Bereich fällt. Die Erstberatung ist kostenlos und unverbindlich.
