Medizinische Softwareentwicklung ist einer der wenigen Bereiche, in denen „wir bauen schnell ein MVP und sehen dann weiter" eine schlechte Idee sein kann. Nicht, weil die Technik schwieriger wäre – sie ist vergleichbar. Sondern weil vom ersten Tag an Vorschriften gelten, die sich später nicht mehr nachrüsten lassen. Dieser Artikel ist eine praktische Landkarte: Was Sie tatsächlich erfüllen müssen, bevor Sie ein E-Health-Produkt in Polen und der EU veröffentlichen.
1. Gesundheitsdaten sind Daten besonderer Kategorien
Die DSGVO unterscheidet zwischen gewöhnlichen personenbezogenen Daten und jenen nach Art. 9 – Daten besonderer Kategorien. Gesundheitsdaten gehören zur zweiten Gruppe. In der Praxis heißt das: Eine „Einwilligung in den AGB" reicht nicht. Sie brauchen eine ausdrückliche Rechtsgrundlage, eine dokumentierte Verarbeitung und ein höheres Schutzniveau.
Das Minimum, das jedes Audit verlangt:
- Verschlüsselung der Daten bei der Übertragung (TLS) und im Ruhezustand (Datenbank, Backups).
- Zugriffskontrolle und Rollen – die Ärztin sieht ihre Patienten, die Rezeption sieht keine Diagnosen, die Administration liest keine medizinischen Daten ohne Anlass.
- Ereignisprotokoll (Audit-Log) – wer wann auf welche Daten zugegriffen hat. Das ist eine der ersten Fragen bei einer Prüfung.
- Datenminimierung – erheben Sie nur, was wirklich nötig ist. Jedes zusätzliche Feld ist ein zusätzliches Risiko.
- Auftragsverarbeitungsverträge (AVV/DPA) mit jedem Dienstleister, der mit den Daten in Berührung kommt: Hosting, Backup, Monitoring, E-Mail.
GRUNDREGEL, die Ärger erspart: Hosten Sie die Daten in der EU. Eine Cloud außerhalb Europas ist möglich, erfordert aber Standardvertragsklauseln und eine Transfer-Folgenabschätzung – für ein kleines Produkt eine unnötige Komplikation.
2. Ist Ihre App ein Medizinprodukt? MDR und Software
Das ist eine Frage im Wert von zehntausenden Euro. Die MDR-Verordnung (2017/745) besagt, dass Software ein Medizinprodukt ist, wenn der Hersteller sie unter anderem zur Diagnose, Überwachung, Behandlung oder Linderung einer Krankheit bestimmt hat.
Konkrete Beispiele für medizinische Software:
- Kein Medizinprodukt: Terminbuchung, Praxiskalender, SMS-Erinnerungen, ein einfaches Befindlichkeitstagebuch, ein Informationsportal, Abrechnungen.
- Medizinprodukt: eine App, die eine Medikamentendosis berechnet, EKGs oder Bilder auswertet, eine Diagnose vorschlägt, ein Krankheitsrisiko klassifiziert oder ein Medizingerät steuert.
Ist Ihr Produkt ein Medizinprodukt, erwarten Sie: MDR-Klassifizierung der Software (bei Software meist Klasse IIa), ein Qualitätsmanagementsystem (ISO 13485), eine Risikoanalyse (ISO 14971), eine klinische Bewertung und eine benannte Stelle. Dieser Prozess dauert Monate und kostet ein Budget in der Größenordnung der Entwicklung selbst – manchmal mehr.
Praktische Schlussfolgerung: Die Grenze „Medizinprodukt / kein Medizinprodukt" ergibt sich vor allem aus der deklarierten Zweckbestimmung. Deshalb lohnt es sich, bei der ersten Produktversion bewusst auf der sicheren Seite zu bleiben: Eine App, die „Messwerte erfasst und sie der Ärztin zeigt", ist etwas anderes als eine App, die „das Herzinfarktrisiko bewertet".
3. Cybersicherheit und technische Normen
Auch außerhalb der MDR lohnt es sich, Standards einzuhalten, denn Kliniken und Praxen fragen in Ausschreibungen immer häufiger danach:
- ISO 27001 – Managementsystem für Informationssicherheit (eine formale Zertifizierung wird bei größeren Kunden mitunter verlangt).
- HL7 / FHIR – Standard für den Austausch medizinischer Daten; ohne ihn ist die Integration mit Krankenhaussystemen mühsam.
- E-Rezept, E-Überweisung, P1 – soll das Produkt an das polnische Gesundheitsökosystem andocken, ist die Anbindung an die staatliche polnische Plattform P1 ein eigenes, gut dokumentiertes Thema.
4. Was kostet das?
Bei marktüblichen Sätzen (bei uns: Entwicklung 46 €/h, Design 35 €/h netto):
Euro-Beträge umgerechnet zum NBP-Mittelkurs vom 14.09.2026 (1 € = 4,3391 zł) und gerundet. Die Abrechnung erfolgt in PLN.
Registrierung, Patienten- und Arztkonten, Kalender, Dokumente, Administrationspanel, vollständige DSGVO-Konformität.
Audit-Log, Verschlüsselung, Rollen, Verarbeitungsdokumentation, Sicherheitstests, AVV mit Dienstleistern.
ISO 13485, technische Dokumentation, klinische Bewertung, benannte Stelle. Hier brauchen Sie zusätzlich einen Regulatory-Affairs-Berater – wir verantworten die Software, nicht die Zertifizierung.
5. Womit Sie anfangen
Bevor Sie eine Zeile Code schreiben, beantworten Sie drei Fragen: Welche Daten müssen Sie wirklich erheben, stellt das Produkt eine Diagnose oder empfiehlt es eine Behandlung und wer ist der Verantwortliche für die Daten. Diese drei Antworten entscheiden über Architektur, Budget und darüber, ob Sie den MDR-Weg gehen.
Bei CodePort entwickeln wir Systeme für Medizin und E-Health genau in dieser Reihenfolge: Zuerst klären wir den regulatorischen Rahmen, dann entwerfen wir. Die umgekehrte Reihenfolge kann teuer werden.
Dieser Artikel ist informativ und stellt keine Rechtsberatung dar. Arbeiten Sie bei Projekten, die unter die MDR fallen, mit einem Regulatory-Affairs-Berater zusammen.