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 legen wir Zweckbestimmung und Datenflüsse so auf den Tisch, dass die Frage „Medizinprodukt oder nicht?“ in einem Termin entschieden werden kann. An ihr hängt ein erheblicher Teil des Aufwands.
Unverbindlich · Antwort innerhalb von 24 Stunden (Mo–Fr) · Direkt aus der Entwicklung, nicht vom Vertrieb
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 oder Achtsamkeit ohne Krankheitsbezug? Dann ist das ein normales App-Projekt – Ablauf und Preise stehen hier.
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.
Zwei Details, die wir früh mit dir durchgehen. Erstens Prävention: „Verhütung“ von Krankheiten ist nach Art. 2 Nr. 1 MDR ein medizinischer Zweck – eine App gegen eine bestimmte Krankheit (Sturz-, Diabetes-, Rückfallprävention) kann also im regulierten Bereich landen, allgemeine Gesundheitsförderung nicht. Zweitens Werbetexte – auch sie zählen zur Zweckbestimmung. Wer „erkennt Herzrhythmusstörungen“ auf die Website schreibt, hat damit unter Umständen ein Medizinprodukt erklärt, auch wenn die App technisch dasselbe tut wie vorher.
Die rechtliche Einordnung trifft eine Regulatory-Beratung – wir liefern ihr die technische Grundlage. Falls du noch keine hast, nennen wir dir passende Häuser.
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, nachvollziehbare Änderungshistorie. Die Schnittstellenschicht bauen wir so, dass spätere Anbindungen nicht am Datenmodell scheitern.
Apple HealthKit, Google Health Connect, Garmin-API. Vitalwerte, Aktivität und Schlaf landen nur nach ausdrücklicher Freigabe in der App – und dürfen nach den Plattformregeln nie für Werbung genutzt werden.
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.
Über 500.000 Downloads über alle Apps, Flutter für iOS und Android aus einer Codebasis, Backends in Go und .NET im produktiven Betrieb – die Referenzen reichen von Zeiterfassung mit Schichtplanung bis zur Lade- und Strompreis-App mit Live-Daten.
Am nächsten an einem Gesundheitsprojekt liegt Klaimo, unsere eigene Fitness-App. Die App verarbeitet Aktivitätsdaten aus der Garmin-API, die Nutzerinnen und Nutzer nach Kontoverknüpfung ausdrücklich freigeben, wertet GPS-Fahrten in Echtzeit in einem Go-Backend auf Cloud Run aus und läuft mit Abo-Modell in beiden Stores. Einwilligungsführung, Wearable-Anbindung und Datenhaltung für sensible Bewegungsdaten – genau die Bausteine, die eine Gesundheits-App braucht.
Die „App auf Rezept“ ist das am häufigsten genannte Ziel in Erstgesprächen. Drei Dinge, die du wissen solltest, bevor du darauf hinplanst.
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 den Nutzen bereits bei Aufnahme belegen; 34 haben ihn in der Erprobung nachgeholt, 16 wurden gestrichen. Unterm Strich schaffen rund zwei Drittel den Nachweis – aber die wenigsten sofort. Wer eine DiGA plant, plant eine Studie und nicht nur eine App.
Zwei Zertifikate, und beide betreffen unsere Ebene. Das BfArM verlangt einen Nachweis zur Datensicherheit nach BSI TR-03161 (§ 139e Abs. 10 SGB V, seit 01.01.2025) und ein Datenschutz-Zertifikat nach Art. 42 DSGVO (§ 139e Abs. 11 SGB V, seit 01.08.2024). Geprüft werden App, Backend und die Schnittstellen dazwischen – also das, was wir bauen. Eine Architektur, die das von Anfang an mitdenkt, spart den teuren Umbau vor der Prüfung.
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 mit einem festen Betrag je Freischaltcode sind damit überholt.
Wer das vor dem Angebot weiß, plant anders – und meistens günstiger. Für viele Ideen, die als DiGA gedacht waren, ist der schnellere Weg eine App ohne Zulassung, die den regulierten Weg später gehen kann. Genau diese Entscheidung bereiten wir im Erstgespräch vor. Erprobungsfristen, Marktzahlen und den Weg ins BfArM-Verzeichnis beschreibt der 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 so aufbereiten, dass die Medizinprodukt-Frage in einem Termin entschieden werden kann. Ergebnis: eine schriftliche Architektur- und Budgetskizze – kostenlos.
Datenmodell, Hosting-Regionen, Einwilligungskonzept und Schnittstellen. Hier entscheidet sich 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 sind Erfahrungswerte aus unseren Projekten; Grundlage des Festpreises ist der im Erstgespräch abgestimmte Leistungsumfang. Medizinprodukte kalkulieren wir nach einer kostenpflichtigen Konzeptphase individuell. Zulassungskosten – Prüfstelle, Benannte Stelle, klinische Bewertung – sind nicht enthalten.
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 rechtliche Einordnung trifft eine Regulatory-Beratung; wir bereiten sie technisch so vor, dass sie in einem Termin fällt.
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. Medizinprodukte kalkulieren wir individuell nach einer Konzeptphase, weil Dokumentation und Abstimmung mit der Regulatory-Beratung den Umfang bestimmen. Zulassungskosten sind nicht enthalten. Wenn der Leistungsumfang nach dem Erstgespräch klar ist, bekommst du ein Festpreisangebot.
Die Software und die Dokumentation aus der Entwicklung – ja. Qualitätsmanagementsystem, klinische Bewertung und Konformitätsbewertung sind Aufgaben einer Regulatory-Beratung, die du beauftragst und der wir aus der Entwicklung heraus zuarbeiten; Hersteller im Sinne der MDR ist der Auftraggeber. Diese Trennung ist Absicht: Entwicklung und Zulassung sind verschiedene Berufe, und ein Anbieter, der beides nebenbei macht, macht meist eines davon schlecht.
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. Für Garmin-Geräte gibt es eine eigene API, die wir ebenfalls anbinden.
Wir melden uns Mo–Fr innerhalb von 24 Stunden mit einer ehrlichen Einschätzung – zu Aufwand und Budget, plus der technischen Grundlage für die Frage „Medizinprodukt oder nicht?“. Die Erstberatung ist kostenlos und unverbindlich.
