Digital-Health-Unternehmen, deren App zum Medizinprodukt geworden ist.

Eine iOS- oder Android-App, ihr Cloud-Backend und ihr Web-Dashboard fallen unter die EU MDR und in den USA unter die FDA-Regeln für Softwarefunktionen von Geräten, sobald sie einen medizinischen Zweck haben. Die Benannte Stelle (die unabhängige Organisation, die ein Produkt nach der EU MDR zertifiziert) oder die FDA liest die Softwaredokumentation, und eine Akte nach IEC 62304 ist der anerkannte Weg, sie zu liefern. Die App wird jede Woche ausgeliefert, und die Akte muss Schritt halten. Wir schreiben die Akte nach IEC 62304 für Software, die bereits im Einsatz ist, und entwickeln die nächsten Releases darunter, innerhalb Ihres Qualitätssystems. Unsere Regulatory-Spezialisten und FDA-Berater schreiben und prüfen die Akte, die Risikoanalyse und die Cybersicherheitsdokumentation und begleiten Sie durch die Einreichung.

30-minütiges Gespräch buchen Schreiben Sie uns

Systeme: iOS · Android · Cloud · Web-Dashboard
Normen: EU MDR · FDA · IEC 62304 · ISO 14971 · ISO 13485
Erster Schritt: Kostenloses 30-minütiges Gespräch mit der Entwicklung

Der Weg der Software

So entsteht ein Release für eine Gesundheits-App unter der MDR.

Anforderung

Die App-Store-Beschreibung und die Werbeaussagen bestimmen die Zweckbestimmung der App. Eine schriftliche Spezifikation fehlt.

VerbesserungWir halten die Anforderungen in einer Spezifikation fest und verknüpfen sie mit dem Code und den Tests.

Design

Nur die Entwickler kennen die Architektur von App, Backend und Dashboard.

VerbesserungWir dokumentieren die Architektur und die SOUP-Liste und aktualisieren beides mit jedem Release.

Implementierung

Open-Source-Bibliotheken und SDKs gelangen ohne Nachweis in den Build.

VerbesserungWir erfassen jede neue Bibliothek und jedes neue SDK in der SOUP-Liste, sobald sie in den Build gelangen.

Verifizierung

Risikoanalyse und Testprotokolle entstehen erst nach dem Code, wenn überhaupt.

VerbesserungVor dem Release testen wir falsch angezeigte Werte, Datenverluste bei der Synchronisierung und die Zuordnung eines Datensatzes zum falschen Patienten.

Freigabe

Die ausgelieferte Version lässt sich nicht der Version zuordnen, die die Benannte Stelle oder die FDA geprüft hat.

VerbesserungDie CI-Pipeline erstellt die Release-Dokumentation. So lässt sich jede ausgelieferte Version ihrer Prüfung zuordnen.

Feldsupport

Abstürze, Beschwerden und Änderungen am Modell einer KI-Funktion werden an unterschiedlichen Stellen erfasst.

VerbesserungWir erfassen Anomalien und Beschwerden in einer gemeinsamen Liste. Jede Modelländerung durchläuft das Change Control.

Änderung

Change Control, Risikobewertung und Testnachweise verzögern die wöchentlichen Releases.

VerbesserungDas Change Control läuft in der Pipeline. So kann die App weiterhin jede Woche ein Release erhalten.

Das Ziel

Eine Gesundheits-App, die trotz MDR ihr Release-Tempo hält.

Für das Unternehmen

Softwaredokumentation für die Benannte Stelle und die FDA, die zum freigegebenen Code passt
Ein regulatorischer Weg, an dem sich das ganze Unternehmen orientieren kann
Wöchentliche Releases, die den Design Controls entsprechen

Für Kliniker

Patientendaten, auf die sich Kliniker verlassen können, genau so, wie die App sie erfasst hat
Alarme, die auch bei Verbindungsabbruch wie spezifiziert funktionieren
Updates, die das gewohnte Verhalten beibehalten

Für Patienten

Verbesserungen an der App, die Patienten jede Woche erreichen und die vor dem Release verifiziert wurden
Schnell behobene Fehler
Messwerte, die ihre Ärztin oder ihren Arzt ohne Verlust oder Verwechslung erreichen

Probleme und Lösungswege

Was wir hören und was wir dagegen tun

Die App ist bereits im Einsatz, aber die IEC-62304-Dokumentation fehlt.

Zuerst klären wir, ob die laufende App bereits als Medizinprodukt am Markt ist, denn das bestimmt den Weg. Dann deckt eine Gap-Analyse (eine Prüfung, was gegenüber der Norm fehlt) von Code, Dokumenten und Prozess den mobilen Code, die Cloud-Dienste und das Dashboard unter einer gemeinsamen Sicherheitsklassifizierung ab. Danach rekonstruieren wir aus dem Code die Anforderungen, die Architektur, die SOUP-Liste (Software unbekannter Herkunft, also Code von Drittanbietern, der im Gerät verwendet wird), die Risikoanalyse und die Testprotokolle, in Ihren Vorlagen und mit Ihren Entwicklern in kurzen Sitzungen.

Retrospektive IEC-62304-Dokumentation

Die Agentur, die die App entwickelt hat, ist nicht mehr verfügbar.

Wir analysieren und dokumentieren den Code, den die Agentur oder das Freelancer-Team hinterlassen hat. Anschließend übernehmen wir die nächsten Releases, während das Produkt auf dem Markt bleibt. Die Design Controls gelten ab der ersten Änderung.

Modernisierung und Übernahme von Altsystemen

Wir releasen jede Woche, und das Qualitätsmanagementsystem wird uns bremsen.

Das Change Control läuft in der CI-Pipeline. So behält die App ihren wöchentlichen Release-Rhythmus in den Stores. Vor jedem Release prüfen wir, ob eine Änderung die Genehmigung der Benannten Stelle oder eine neue FDA-Einreichung erfordert. Jede Änderung ist mit ihrer Anforderung, Risikobewertung und den Testnachweisen verknüpft. Für jedes Release erstellen wir eine Versionsdokumentation und eine Liste bekannter Anomalien.

Entwicklung medizinischer Software

Wir brauchen Spezialisten für Regulatory Affairs, die gemeinsam mit uns die Dokumentation und die Einreichung vorbereiten.

Unsere Regulatory-Spezialisten und FDA-Berater schreiben die technische Dokumentation, die Risikomanagementakte und die Cybersicherheitsdokumentation mit Ihrem Team und prüfen sie vor der Einreichung gegen die MDR und die FDA-Leitfäden. Sie beraten zur Klassifizierung und zur Einreichungsstrategie, schreiben die FDA Pre-Submission und beantworten mit Ihnen die Fragen der Benannten Stelle (die unabhängige Organisation, die ein Produkt nach der EU MDR zertifiziert) oder der FDA. Das Threat Model (eine strukturierte Analyse, wie das Gerät angegriffen werden könnte), die SBOM (Software Bill of Materials, die Liste aller Softwarekomponenten im Build) und der Schwachstellenprozess werden mit der Architektur geschrieben, nach IEC 81001-5-1 und Abschnitt 524B.

QA, Compliance und Regulatorik

Wir haben eine KI-Funktion ergänzt und wissen nicht, welche Auswirkungen sie hat.

Wir erfassen das Modell mit seinen Trainingsdaten, Verifizierungsergebnissen und dem Change Control als versioniertes Konfigurationselement. Bei einer neuen KI-Funktion in einem zertifizierten Produkt prüfen wir, ob sie eine wesentliche Änderung darstellt. Sie kann eine Genehmigung der Benannten Stelle und eine aktualisierte klinische Bewertung erfordern. In den USA können eine neue Einreichung oder ein PCCP erforderlich sein. Wir ergänzen die MDR-Dokumentation um die Modellbeschreibung und die Leistungsnachweise.

Vom KI-Modell zum Medizinprodukt

Eignung

Wann wir der richtige Partner sind

Sprechen Sie uns an, wenn

Sie die IEC-62304-Dokumentation für eine laufende App brauchen, nach der die Benannte Stelle oder die FDA fragt
Sie eine App und ein Backend übernehmen möchten, die eine Agentur oder ein Freelancer-Team entwickelt und hinterlassen hat
Sie in einem Produkt, das bereits ein Medizinprodukt ist, eine KI-Funktion einsetzen und die Dokumentation aktualisieren möchten
Sie mit Spezialisten für Regulatory Affairs die Dokumentation und die FDA Pre-Submission erstellen möchten

Sprechen Sie mit uns

Sagen Sie uns, woran Sie arbeiten.

Eine laufende App ohne Dokumentation, mit anstehender Einreichung oder mit einer neuen KI-Funktion. Beschreiben Sie kurz Ihr Produkt, seine Plattformen und die bereits vorhandenen Dokumente. Alternativ können Sie ein kostenloses 30-minütiges Gespräch mit der Entwicklung buchen.

30-minütiges Fachgespräch buchen

FAQ

Häufige Fragen.

Ist unsere Gesundheits-App ein Medizinprodukt nach der MDR oder für die FDA?

Es entscheidet die Zweckbestimmung, die Ihr Unternehmen angibt. In der EU gilt Software, die Informationen für Diagnose oder Therapie liefern soll, als Medizinprodukt, wie MDCG 2019-11 erläutert, und wird nach Anhang VIII Regel 11 in Klasse IIa oder höher eingestuft. In den USA ziehen die FDA-Leitlinien zu Softwarefunktionen von Medizinprodukten, zur klinischen Entscheidungsunterstützung und zu General Wellness die Grenze. Der Weg führt über eine 510(k) (die FDA-Vormarktmeldung für ein Produkt, das einem bereits vermarkteten ähnelt), einen De-Novo-Antrag oder eine PMA. Wir dokumentieren die Software passend zur jeweiligen Klasse und zum jeweiligen Weg.

Können Sie die IEC-62304-Dokumentation für eine App erstellen, die bereits im Einsatz ist?

Ja. Wir beginnen mit einer Gap-Analyse von Code, Dokumenten und Prozess. Dann rekonstruieren wir die SRS, die Architektur, die SOUP-Liste, die Software-Risikoanalyse und die Testprotokolle aus dem Code, in Ihren Vorlagen und innerhalb Ihres QMS (Qualitätsmanagementsystem).

Entwickeln Sie auch die App und das Backend oder erstellen Sie nur die Dokumentation?

Beides. Unsere Entwickler entwickeln mobile Apps, Cloud-Backends und Web-Dashboards und halten die IEC-62304-Dokumentation parallel zum Code aktuell. Bei einer Begleit-App für ein Wearable verifizieren wir App, Bluetooth-Verbindung und Backend gemeinsam mit dem Gerät als ein System.

Können Sie eine FDA Pre-Submission für unsere App vorbereiten?

Ja. Unsere FDA-Berater erstellen die Pre-Submission (Q-Submission) mit Produktbeschreibung, Zweckbestimmung, vorgeschlagenem Verfahren und Fragen an die FDA. Sie bereiten Ihr Team auch auf das Meeting vor. Dasselbe Team erstellt die zugehörige Software-, Risiko- und Cybersicherheitsdokumentation.

Können wir unter IEC 62304 weiterhin jede Woche ein Release veröffentlichen?

Ja, wenn das Change Control in die Pipeline eingebunden ist. Jede Änderung ist mit ihrer Anforderung, Risikobewertung und den Testnachweisen verknüpft. Jedes Release erhält einen Versionsnachweis und eine Liste bekannter Anomalien.

Wie lange dauert eine Gap-Analyse und was kostet sie?

Das Standard-Review dauert drei Wochen. Sie erhalten anschließend einen schriftlichen Bericht und einen Maßnahmenplan. Bei einer App mit Backend und Dashboard legen wir die Dauer fest und nennen den Preis nach einer ersten Prüfung von Code und Dokumenten.

Weiterführend