Freelance Software-Entwickler Medizinprodukte (IEC 62304)

Aufgaben und Anforderungen im Überblick

Typische Projektanlässe

• Entwicklung einer neuen SaMD-Anwendung mit MDR-Zertifizierung
• Hochstufung von Software nach MDR Regel 11 mit nötigem Prozessausbau
• Lücken in Architektur- und Testdokumentation nach Audit
• Kapazitätsengpass in Embedded-Teams aktiver Geräte
• Migration von Legacy-Code oder Plattformwechsel mit Neubewertung
• Vorbereitung auf die zweite Ausgabe der IEC 62304

Was ein Software-Entwickler nach IEC 62304 im Projekt leistet

Ein Software-Entwickler für Medizinprodukte schreibt nicht nur Code, sondern liefert die Nachweise, dass dieser Code nach einem definierten Lebenszyklusprozess entstanden ist. IEC 62304 beschreibt diesen Prozess: Planung, Anforderungsanalyse, Architektur, detailliertes Design, Implementierung und Verifikation von Einheiten, Integration, Systemtest und Freigabe, ergänzt um Wartung, Risikomanagement, Konfigurationsmanagement und Problemlösung. Welche Aktivitäten Pflicht sind, hängt von der Software-Sicherheitsklasse A, B oder C ab.

Im Freelance-Projekt arbeiten Sie typischerweise in einem Entwicklungsteam des Herstellers, häufig agil organisiert. Ihre Rolle reicht je nach Erfahrung vom Entwickler mit klar umrissenen Komponenten bis zum Software-Architekten, der Segregation, Schnittstellen und Sicherheitskonzept verantwortet. Schnittstellen bestehen zum Systems Engineering, zum Risikomanagement, zu V&V-Engineers, zum Cybersecurity-Team, zu Regulatory Affairs und zur Qualitätssicherung, die Prozesskonformität prüft.

Typisch für diese Rolle sind Spannungsfelder: Agilität und Dokumentationspflicht, Open-Source-Bibliotheken und SOUP-Bewertung, schnelle Releases und Änderungsbewertung. Erfahrene Freelancer wissen, wie man Dokumentation aus dem Entwicklungsprozess heraus erzeugt – etwa durch Traceability im ALM-Tool, automatisierte Testberichte und versionierte Architekturbeschreibungen – statt sie nachträglich zu schreiben.

Typische Software-Projekte und Deliverables

Die Projektlandschaft reicht von Standalone-Software bis zu Embedded-Systemen. Häufig sind:

• SaMD: Diagnose- und Therapieunterstützung, Auswertung von Bilddaten, digitale Gesundheitsanwendungen mit Medizinproduktestatus, Apps zur Steuerung von Geräten
• Embedded-Software: Firmware für Infusionspumpen, Beatmungsgeräte, Monitoring-Systeme, Implantate oder Laborgeräte, oft mit Echtzeitanforderungen
• Gerätenahe Software: Bedienoberflächen, Service-Software, Konnektivität zu Krankenhaussystemen über HL7 oder FHIR

Die Deliverables ergeben sich aus IEC 62304 und werden häufig direkt im ALM-System geführt:

• Software-Entwicklungsplan, Konfigurations- und Problemlösungsplan
• Software Requirements Specification mit Verknüpfung zu Systemanforderungen und Risikokontrollmaßnahmen
• Software-Architektur mit Einheiten, Schnittstellen, SOUP und Segregationskonzept
• Detailliertes Design für Klasse-C-Einheiten
• Unit-Tests, Integrationstests, Code-Reviews, statische Analyse und Testberichte
• SOUP-Liste mit Anforderungen, bekannten Anomalien und Bewertung
• Release Notes mit bekannten Restanomalien und Freigabedokumentation

In vielen Projekten kommt die Pflege bestehender Software hinzu: Fehlerbehebungen, Anpassungen an neue Betriebssysteme oder Bibliotheksversionen, jeweils mit Änderungsbewertung. Gerade bei SOUP-Updates aus Sicherheitsgründen ist schnelle, aber dokumentierte Entscheidungsfähigkeit gefragt.

Typische Probleme, die Freelancer lösen sollen

• Die Architektur beschreibt nicht, wie sicherheitsrelevante Einheiten von weniger kritischen getrennt sind, sodass die gesamte Software als Klasse C behandelt werden müsste.
• Unit-Tests existieren, sind aber nicht mit Anforderungen und Risikokontrollmaßnahmen verknüpft.
• Open-Source-Bibliotheken wurden ohne SOUP-Bewertung eingebunden, bekannte Schwachstellen sind nicht dokumentiert.
• Nach einer Höherklassifizierung durch Regel 11 fehlen Prozesse, die für Klasse IIa oder IIb erwartet werden, etwa formale Problemlösung und Änderungsbewertung.

Solche Lücken lassen sich nicht allein durch Dokumentation schließen. Oft sind Refactoring, zusätzliche Tests oder eine überarbeitete Architektur nötig, damit die Nachweise tatsächlich stimmen.

Normen und Leitlinien für Medical-Device-Software

IEC 62304:2006 mit Amendment 1:2015 ist die maßgebliche Norm für den Software-Lebenszyklus, als EN 62304 unter der MDR harmonisiert. Eine zweite Ausgabe ist in Arbeit; sie soll den Anwendungsbereich auf Health Software erweitern und die drei Sicherheitsklassen durch zwei Stufen der Prozessstrenge ersetzen. Bis die neue Ausgabe veröffentlicht und auf europäischer Ebene übernommen ist, bleibt die bestehende Fassung Prüfmaßstab. Für die Einordnung als Medizinprodukt und die Klassifizierung ist MDCG 2019-11, im Juni 2025 als Revision 1 aktualisiert, die zentrale Leitlinie.

Für Software mit KI-Komponenten ist zusätzlich die KI-Verordnung (EU) 2024/1689 relevant. Für Medizinprodukte, die als Hochrisiko-KI gelten, wurden die Pflichten durch die Digital-Omnibus-Verordnung auf den 2. August 2028 verschoben. Für US-Projekte gelten die FDA-Leitlinie zu Content of Premarket Submissions for Device Software Functions von 2023 sowie die QMSR.

Qualifikation und Erfahrung, die Auftraggeber erwarten

Auftraggeber erwarten in der Regel mehrere Jahre professionelle Softwareentwicklung, davon idealerweise mindestens zwei Jahre unter IEC 62304. Erfahrung aus anderen sicherheitskritischen Bereichen wie Automotive (ISO 26262), Bahn (EN 50128) oder Luftfahrt (DO-178C) wird oft anerkannt, weil die Prinzipien – Anforderungsrückverfolgung, Verifikation, Konfigurationsmanagement – vergleichbar sind.

Technisch hängt das Profil stark vom Produkt ab. Für Embedded-Projekte sind C und C++, Echtzeitbetriebssysteme, MISRA-Regeln und hardwarenahe Tests gefragt. Für SaMD und gerätenahe Anwendungen dominieren C#, Java, Python, TypeScript, Cloud-Architekturen und mobile Plattformen. In beiden Bereichen sind Erfahrungen mit Testautomatisierung, statischer Codeanalyse und CI/CD wichtig.

Darüber hinaus erwarten Auftraggeber:

• Verständnis der Sicherheitsklassifizierung und ihrer Folgen für Dokumentation und Tests
• Fähigkeit, SOUP fachgerecht zu bewerten und Anomalien zu verfolgen
• Disziplin in Code-Reviews, Branching-Strategien und Release-Management
• Kenntnis von Security-Grundlagen nach IEC 81001-5-1
• Erfahrung mit ALM-Tools und Traceability

Stundensatz und Konditionen für IEC-62304-Entwickler

Als Orientierung liegen Stundensätze erfahrener freiberuflicher Software-Entwickler für Medizinprodukte zwischen 85 und 120 Euro netto pro Stunde ohne Reisekosten. Die Spanne ist eine Einschätzung aus der Projektpraxis und keine Marktstatistik.

In den oberen Bereich führen Architekturverantwortung, Klasse-C-Software, seltene Embedded-Kompetenzen, Erfahrung mit KI-basierten Medizinprodukten und Kombination aus Entwicklung und regulatorischer Prozesskompetenz. In den unteren Bereich führen reine Implementierungsaufgaben in Klasse-A-Software, lange Rahmenverträge mit hoher Auslastung oder vollständig remote durchgeführte Standardentwicklung.

Bei Embedded-Projekten sollten Sie klären, ob Prototypen und Testequipment beim Auftraggeber verbleiben oder ob Sie Hardware im Homeoffice nutzen dürfen. Das beeinflusst den realistischen Remote-Anteil und damit die Reisekosten.

Remote-Arbeit in der Medical-Device-Software

Softwareentwicklung für Medizinprodukte gehört zu den Rollen mit dem höchsten Remote-Anteil. SaMD-Projekte laufen häufig vollständig remote, Abstimmungen erfolgen in agilen Ritualen per Video, Code und Dokumentation liegen in zentralen Repositories und ALM-Systemen. Präsenz beschränkt sich oft auf Kick-offs, Planungsworkshops und gelegentliche Teamtage.

Bei Embedded-Software ist die Lage differenzierter. Hardwarenahe Entwicklung, Integrationstests am Gerät und Fehlersuche mit Messgeräten erfordern Zugang zum Labor. Manche Auftraggeber stellen Entwicklungsboards für das Homeoffice zur Verfügung, andere verlangen Präsenz für alle Arbeiten am Zielsystem. Ein Modell mit regelmäßigen Labortagen ist hier verbreitet.

Unabhängig vom Produkt gilt: Zugriff auf Repositories und ALM-Systeme erfolgt meist nur über VPN und Firmenkonten. Klären Sie früh, ob eigene Hardware zulässig ist, denn das entscheidet mit darüber, wie flexibel Sie mehrere Mandate parallel betreuen können.

Vertragsmodelle für Software-Entwickler Medizintechnik

Die meisten Mandate laufen als Dienstvertrag, entweder direkt mit dem Hersteller oder über Personaldienstleister und Softwarehäuser, die Entwicklungsleistungen bündeln. Werkverträge kommen vor, wenn ein klar spezifiziertes Modul oder eine Komponente mit definierten Abnahmekriterien geliefert wird. Dann sollten Sie besonders auf die Verantwortung für die IEC-62304-Dokumentation und die Haftung achten.

In agilen Teams mit fester Einbindung in Sprints, Weisungen zu Arbeitsinhalten und Nutzung interner Ressourcen ist die Grenze zur abhängigen Beschäftigung schnell erreicht. Auftraggeber reagieren darauf mit Arbeitnehmerüberlassung oder strengen Vorgaben zur Vertragsgestaltung. Für Sie bedeutet das, die eigene Unternehmereigenschaft durch mehrere Auftraggeber, eigene Arbeitsmittel und ergebnisorientierte Leistungsbeschreibung zu stützen. Diese Hinweise sind allgemeine Information, keine Rechtsberatung.

Abgrenzung zu V&V, Cybersecurity und Regulatory Affairs

Der Software-Entwickler verantwortet Implementierung und Software-Tests auf Einheiten- und Integrationsebene. Der V&V Engineer führt Systemtests und Validierung durch und bringt den unabhängigen Blick ein. Der Cybersecurity-Experte verantwortet Threat Modeling, Security-Architektur und Penetrationstests. Regulatory Affairs übernimmt Klassifizierung, technische Dokumentation und Einreichung.

Gerade in kleineren Unternehmen werden diese Rollen vermischt. Für Ihr Profil lohnt es sich, Schwerpunkte zu nennen: Embedded oder SaMD, Architektur oder Implementierung, gegebenenfalls Security oder KI. Wer Code und IEC-62304-Prozess gleichermaßen beherrscht, ist für Hersteller besonders wertvoll, weil Nachweise nicht nachträglich rekonstruiert werden müssen.

Wer aus der klassischen Softwareentwicklung in die Medizintechnik wechselt, sollte vor dem ersten Mandat die Grundbegriffe von IEC 62304, ISO 14971 und MDCG 2019-11 sicher beherrschen. Ein kleines Referenzprojekt mit vollständiger Traceability, etwa aus einer früheren Festanstellung, ist für Auftraggeber ein überzeugender Nachweis, dass Sie Entwicklung und Nachweisführung zusammendenken.

Projektbeispiele für Software IEC 62304

Anonymisierte Projektanfragen, wie sie für diese Rolle und verwandte Profile regelmäßig vorkommen.

Häufige Fragen

Allgemeine Information, keine Rechts- oder Steuerberatung. Stundensätze sind Orientierungsspannen, kein Honorarspiegel. Stand: 10/2026.