Medical-Software-Anforderungen — Wissensbasis
Was muss eine medizinische Software in der EU erfüllen — und wo sind die Schmerzpunkte? Diese Seite sammelt jede relevante Verordnung, Norm und Klassifizierung in ausklappbaren Info-Karten mit konkreten Beispielen + Bezug zur MDSW-Factory.
Quellen-Markierung — was ist verifiziert, was ist Schätzung
Verordnungen — der Gesetzesrahmen
Verbindlich. Wer ein Medizinprodukt in der EU in Verkehr bringt, muss diese Texte einhalten. Verstöße = Marktrücknahme + Strafzahlungen + persönliche Haftung der verantwortlichen Person.
MDR — Verordnung (EU) 2017/745 [V] verifiziert # Medical Device Regulation. Geltung seit 26. Mai 2021. Kern-Rahmen für jedes Medizinprodukt in der EU.
Was ist das Thema?
Die MDR löste die alten Richtlinien MDD/AIMDD ab und verschärfte fast alle Anforderungen: strengere Klassifizierung (insbesondere für Software via Anhang VIII Regel 11), Pflicht-PRRC, vollständige technische Dokumentation, klinische Bewertung mit nachweisbarem Stand der Technik, lebenslange Post-Market-Surveillance (PMS) und Vigilanz, EUDAMED-Registrierung mit UDI.
Was wird gefordert?
Jedes Produkt das einen medizinischen Zweck hat (siehe Art. 2 Abs. 1) braucht ein Konformitätsbewertungsverfahren passend zur Klasse, eine CE-Kennzeichnung, eine Konformitätserklärung, eine technische Dokumentation gemäß Anhang II, eine klinische Bewertung gemäß Art. 61, ein QMS gemäß Art. 10 Abs. 9 und einen PRRC gemäß Art. 15.
Beispiele
- Eine Smartphone-App die Symptome trackt und Empfehlungen für Selbstbehandlung gibt, fällt unter MDR und wird via Regel 11 typischerweise als Klasse IIa eingestuft.
- Eine reine Erinnerungs-App ohne Empfehlung fällt eher unter Klasse I (Selbstdeklaration).
- Klinische Software die Bilder befundet wird Klasse IIb-III, abhängig vom Risiko bei Fehlbefund.
Bezug zur Factory
Die MDSW-Factory generiert die Anhang-II-Dokumentation als Skelett (Art. 2.4 Track), die Risikoanalyse-Drafts (Track 2.3) und die klinische Literatur-Vor-Recherche (Track 2.7). Endgültiges Sign-Off bleibt PRRC + Klin.Sachv.
MDR — Verordnung (EU) 2017/745 — Einzelbestimmungen
Art. 15 — PRRC (Person Responsible for Regulatory Compliance) [V] verifiziert #
Was ist das Thema?
Jeder Hersteller muss mindestens eine natürliche Person mit definierter Qualifikation benennen, die intern für die Einhaltung der MDR verantwortlich ist. Diese Person zeichnet die Konformitätserklärung mit, prüft die technische Dokumentation, überwacht Vigilanz und PMS.
Beispiele
- PRRC-Qualifikation laut Art. 15 Abs. 1: Diplom in Recht/Medizin/Pharmazie/Ingenieurwesen ODER 4 Jahre Berufserfahrung in regulatorischen Angelegenheiten / QMS für Medizinprodukte.
- Bei Kleinstunternehmen + Mikrounternehmen darf PRRC extern beauftragt werden (Art. 15 Abs. 2).
- Bei größeren Herstellern muss PRRC fest in der Organisation sein.
Bezug zur Factory
Jedes Spinoff in Schicht C braucht einen eigenen PRRC. Die Factory liefert ihm das Material vorbereitet — er reviewt + signiert.
Art. 51 + Anhang VIII — Klassifizierung [V] verifiziert #
Was ist das Thema?
Anhang VIII enthält 22 Regeln zur Risikoklassifizierung. Für Software ist Regel 11 (eingeführt durch MDR, gab es in MDD nicht) maßgeblich: Software, die Diagnose- oder Therapieentscheidungen unterstützt, ist Klasse IIa oder höher; Software, die nur Daten überwacht / verwaltet, kann Klasse I sein.
Beispiele
- Klasse I: reine Pflegedokumentation, Termin-Erinnerungs-Apps, Vital-Werte-Eingabe ohne Bewertung.
- Klasse IIa: Symptom-Checker mit Triage-Empfehlung, Dosis-Kalkulator, Medikamenten-Interaktions-Checker.
- Klasse IIb: Insulin-Anpasser, EKG-Rhythmus-Erkennung, Sepsis-Frühwarner.
- Klasse III: Lebensentscheidende Software (Beatmungs-Algorithmen, Defibrillator-Steuerung).
Bezug zur Factory
Bei jedem neuen Spinoff erstellt die Factory einen Klassifizierungs-Vorschlag basierend auf Decision-Tree MDCG 2019-11. PRRC + Anwalt bestätigen final — der KI-Vorschlag ist nicht bindend.
Art. 52 Abs. 7 — Klasse-I-Selbstdeklaration [V] verifiziert #
Was ist das Thema?
Klasse-I-Produkte (außer Klasse Im / Is / Ir) brauchen keinen Notified Body. Hersteller deklariert selbst die Konformität — basis sind Tech-Doku, klinische Bewertung, Risikoanalyse, QMS, PRRC. Auf BASG-Anfrage muss alles vorgelegt werden können.
Was wird gefordert?
Vollständige Anhang-II-Doku + Konformitätserklärung + EUDAMED-Registrierung + UDI. Notified Body NICHT involviert. Aber: BASG kann jederzeit nachforderen.
Beispiele
- MedReminder-App: Klasse I, Selbstdeklaration, ~6-9 Wochen Time-to-CE [S].
- Symptom-Diary ohne Interpretation: Klasse I.
- Vital-Werte-Erfassung am Bett: Klasse I (sofern keine Auswertung).
Bezug zur Factory
Hauptzielgruppe der Factory in Phase 3. Hier ist das Verhältnis Factory-Anteil zu Mensch-Aufwand am besten (~70-80% AI-Draft [S]).
Art. 53 — Beteiligung des Notified Body [V] verifiziert #
Was ist das Thema?
Ab Klasse IIa muss ein Notified Body (NB) das Konformitätsbewertungsverfahren prüfen — typisch zweistufig: Stage 1 (Doku-Review off-site) + Stage 2 (On-Site-Audit). NB-Liste in der NANDO-Datenbank: ec.europa.eu/growth/tools-databases/nando/.
Beispiele
- Laut Gemini-Antwort [Q-G]: QMD Services ist Österreichs einziger MDR-NB. Vor Vertragsabschluss via NANDO bestätigen.
- NB-Wartezeit laut [Q-G] 12-18 Monate — schwankt stark, direkt anfragen.
- NB darf nicht beraten, nur prüfen — Beratungsleistung muss von externem Compliance-Berater kommen.
Bezug zur Factory
NB-Audit-Antworten sind Mensch-Pflicht (PRRC + QM). Die Factory liefert lückenlose Audit-Trails als ZIP-Bundle (Track 2.9) — Auditor sieht: AI v0.1 → Human edits → Final v1.0, alle hash-signiert.
Art. 61 + Anhang XIV — Klinische Bewertung [V] verifiziert #
Was ist das Thema?
Pflicht-Nachweis dass das Produkt klinisch sicher und leistungsfähig ist. Drei Wege: (a) eigene klinische Prüfung, (b) Literatur-basierte Bewertung mit Vergleichsprodukt + Stand der Technik, (c) für Klasse I oft mit Plausibilitätsargumentation + bestehender Evidenz möglich.
Was wird gefordert?
Klinischer Bewertungsplan + Klinischer Bewertungsbericht. Aktualisierung mindestens jährlich für Klasse III/IIb-Implantate, sonst regelmäßig laut Plan. Bewertung muss vom medizinisch-klinisch ausgebildeten Sachverständigen final beurteilt werden.
Beispiele
- MedReminder Klasse I: Plausibilität + bestehende Studien zu Adherence-Apps + dokumentierte Limitationen.
- Pädiatrie-Dosiskalkulator IIa: Vergleich zu validierten Tabellenwerken, PubMed-Lit-Review.
- Insulin-Anpasser IIb: eigene klinische Studie mit Patienten-Kohorte, ethik-bewilligt.
Bezug zur Factory
Track 2.7 — AI-Prompt-gestützer PubMed-Query-Builder + Lit-Review-Aggregator. Klin.Sachv. finalisiert die Konklusion (Mensch-Pflicht).
Art. 87-92 — Vigilanz + Trendanalyse [V] verifiziert #
Was ist das Thema?
Hersteller muss schwerwiegende Vorkommnisse („serious incidents") binnen 15 Tagen an die zuständige Behörde melden (in AT: BASG via EUDAMED). Tödliche / schwerwiegend gefährdende Vorkommnisse: 2 Tage. Trends die auf systemisches Problem deuten: ebenfalls meldepflichtig.
Beispiele
- App empfiehlt falsche Insulin-Dosis → Hypoglykämie → 2-Tage-Meldung.
- App stürzt bei bestimmtem Workflow ab und Patient verpasst Medikation → 15-Tage-Meldung wenn Schaden plausibel.
- Mehrere User berichten unklarem Bug (Trend) → Trend-Report.
Bezug zur Factory
Track 1.1 — revisionssicherer Audit-Trail mit Hash-Chain ist Voraussetzung für glaubwürdige Vigilanz-Berichte. Behörde kann jederzeit ZIP-Export anfordern.
Anhang II + III — Technische Dokumentation [V] verifiziert #
Was ist das Thema?
Anhang II definiert die Pflicht-Inhalte der Technischen Doku: Produktbeschreibung, IFU, Designs- und Herstellungsinformationen, Risikoanalyse, Verifikations- und Validierungs-Reports, klinische Bewertung. Anhang III ergänzt um PMS / PSUR.
Beispiele
- Pro Spinoff: ~12 Markdown-Artefakte in standardisierter Struktur — Spec, Architecture, Risk-Analysis, IFU, Test-Plan, V&V-Report, Klin.Eval, SOUP-Report, SBOM, Trace-Matrix, IFU-multi-language, PSUR-Template.
- Bei Klasse I: schlanker, aber alle Sektionen pflicht.
- Bei Klasse IIa: zusätzlich Vergleichs-Vorrichtungs-Analyse + Lit-Review-Tiefe.
Bezug zur Factory
Track 2.4 — MDR-Anhang-II-Skelett-Generator + PDF-Export für NB. Auto-Update bei Code-Change via Track 2.5 Trace-Matrix.
Anhang VIII Regel 11 — Software-Klassifizierung [V] verifiziert #
Was ist das Thema?
Regel 11 wurde mit der MDR neu eingeführt und ist der häufigste Streitpunkt bei Software-Klassifizierung. Sinngemäß: Software die Informationen liefert, die zu Diagnose- oder Therapie-Entscheidungen herangezogen werden, ist mindestens Klasse IIa. Bei lebenswichtigen Entscheidungen: IIb-III.
Beispiele
- Software liefert "nur Daten" (Pulswerte aus Sensor anzeigen) → typisch Klasse I.
- Software gibt "Empfehlung" (z.B. zur Triage) → Klasse IIa.
- Software trifft "Therapie-Entscheidung" (z.B. Insulin-Dosis errechnen für Patient) → Klasse IIb.
- Software steuert lebensentscheidendes System → Klasse III.
Bezug zur Factory
Decision-Tree gemäß MDCG 2019-11 ist Vorab-Eingabe in den Spinoff-Bootstrapper. Klassifikation wird vorgeschlagen, PRRC bestätigt.
IVDR — Verordnung (EU) 2017/746 [V] verifiziert # In-vitro-Diagnostika-Verordnung. Pendant zur MDR für Diagnostika.
Was ist das Thema?
Regelt In-vitro-Diagnostika (IVDs): Tests an Proben außerhalb des Körpers — Bluttests, Schwangerschaftstests, Genom-Diagnostik. Eigene Klassifikation (A bis D, von harmlos bis lebensbedrohlich). Geltung seit 26. Mai 2022, mit gestaffelten Übergangsfristen.
Was wird gefordert?
Bei IVD-begleitender Software: parallele Klassifikation laut IVDR Anhang VIII. Tech-Doku, klinische Leistungsbewertung (statt klinische Bewertung), Performance-Studien.
Beispiele
- Auswertungs-Software für PCR-Tests → IVD-Software.
- Companion Diagnostic für Krebs-Therapie → IVDR Klasse C/D.
- Reine Datenbank für Laborwerte ohne Auswertung → meist nicht IVD.
Bezug zur Factory
Out-of-scope für die erste Factory-Phase. Bei Bedarf eigenes Adapter-Set, vergleichbar zu MDR.
EU AI Act — Verordnung (EU) 2024/1689 [V] verifiziert # EU-weite Regulierung von KI-Systemen. Sechsschicht-Risikomodell. In Kraft seit 1. August 2024 mit gestaffelten Anwendungsdaten.
Was ist das Thema?
Vier Risikoklassen: unzulässig (Sozialscoring, biometrische Massenüberwachung), hochrisiko (medizinische KI ist hier!), begrenzt (Chatbots) und minimal. Hochrisiko-Pflichten greifen ZUSÄTZLICH zu MDR — also doppelte Compliance-Pflicht für KI-basierte Medizinprodukte.
Was wird gefordert?
Hochrisiko-KI: Konformitätsbewertung, Risikomanagement, Daten- und Daten-Governance, technische Doku, Aufzeichnungen + Logs, Transparenz, menschliche Aufsicht, Robustheit + Cybersecurity, post-market monitoring. Anhang III listet die Hochrisiko-Bereiche, Medizinprodukte fallen dort hinein.
Beispiele
- KI-basierter Hautläsions-Klassifikator (Melanom-Verdacht): MDR IIb + AI-Act Hochrisiko → +60 PT [S] Aufwand.
- KI-basierter Symptom-Checker (Triage): MDR IIa + AI-Act Hochrisiko → +30 PT [S].
- Klassischer deterministischer Dosis-Kalkulator (Lookup-Tabelle): MDR IIa, AI-Act NICHT betroffen → kein Mehraufwand.
Bezug zur Factory
Empfehlung [J]: kein ML in Klasse-I-Spinoffs in der Erstphase. Heuristiken / Lookup-Tabellen sind viel günstiger zu zertifizieren und vermeiden den AI-Act-Layer komplett.
DSGVO — Verordnung (EU) 2016/679 [V] verifiziert # Datenschutz-Grundverordnung. Bei Gesundheitsdaten (Art. 9) gelten verschärfte Anforderungen.
Was ist das Thema?
Gesundheitsdaten sind besondere Kategorie personenbezogener Daten (Art. 9). Verarbeitung grundsätzlich verboten — außer mit ausdrücklicher Einwilligung oder einer der Ausnahmen in Art. 9 Abs. 2. Verstöße werden mit bis zu 4% des weltweiten Jahresumsatzes oder 20 Mio EUR (höherer Wert) geahndet.
Was wird gefordert?
Pflichten: Datenschutz-Folgenabschätzung (Art. 35), Auftragsverarbeitungsvertrag (Art. 28), Verzeichnis der Verarbeitungstätigkeiten (Art. 30), Meldepflicht bei Verletzungen (Art. 33-34, 72h-Frist), DPO-Bestellung bei systematischer Gesundheitsdaten-Verarbeitung (Art. 37).
Beispiele
- Eine Symptom-App speichert User-Eingaben → Art. 9 betroffen → DSFA Pflicht.
- App nutzt US-Cloud (AWS, Azure, GCP) → Schrems-II-Konflikt → keine Übermittlung in unsicheres Drittland.
- Daten-Leck bei 50 Usern → 72h-Meldung an Datenschutzbehörde + ggf. Betroffene.
Bezug zur Factory
Track 1.8 — DSFA-Template generierbar pro neuem Tenant + DPO-Sign-off-Workflow. compliance_profile-Tenant-Flag (Track 1.9) schaltet strikte Einstellungen frei: Verschlüsselung, Audit-Logs, Retention-Limits, EU-only-Hosting.
MPG 2021 — BGBl. I Nr. 122/2021 [V] verifiziert # Österreichisches Medizinproduktegesetz. Nationale Umsetzung der MDR.
Was ist das Thema?
Das MPG 2021 ergänzt die direkt geltende MDR um nationale Vorschriften: BASG als Behörde, Strafbestimmungen, Übergangsbestimmungen, klinische Prüfungen in Österreich, Sprache der IFU (deutsch). Wer in AT in Verkehr bringt, hält MDR + MPG ein.
Was wird gefordert?
Nutzungs- und Beobachtungsbestimmungen, BASG-Anzeigepflichten, IFU-Sprache (deutsch zwingend, plus optional weitere), Vigilanz-Meldungen in AT-Format.
Beispiele
- Klinische Studie in AT: Antrag bei BASG + Ethikkommission, MPG § 47ff.
- IFU einer App: deutsche Version pflicht, englische optional.
- BASG-Inspektion: kann auch Klasse-I-Hersteller treffen, MPG § 67ff.
Bezug zur Factory
IFU-Generator (Track 2.6) erzeugt zwingend deutsche Version + optionale Übersetzungen. AT-Sprach-Quality-Checker integriert.
GTELG § 6 — Logging-Pflicht für Gesundheitsdaten [Q-G] eingangsquelle # Gesundheitstelematikgesetz. Laut [Q-G]: 10 Jahre revisionssichere Aufzeichnung jedes Gesundheitsdaten-Zugriffs.
Was ist das Thema?
Wer Gesundheitsdaten elektronisch verarbeitet, muss laut GTELG § 6 jeden Zugriff (lesend + schreibend) revisionssicher aufzeichnen. Revisionssicher = manipulationssicher (Hash-Chain oder vergleichbares), 10 Jahre aufbewahren, jederzeit auswertbar. Vor Festlegung im Code: Original-Gesetzestext via ris.bka.gv.at prüfen.
Was wird gefordert?
Audit-Log mit Wer + Was + Wann + Welcher Datensatz + Erfolg/Fehler. Logs nicht löschbar, nur archivierbar. Auswertung auf Anfrage von Patient oder Behörde.
Beispiele
- Pflegekraft öffnet Patienten-Akte: Log-Eintrag mit User-ID + Patient-ID + Timestamp.
- Edit eines Werts: vorher/nachher in Audit-Log mit Hash-Signatur.
- Bulk-Export für Forschungs-Zweck: ebenfalls geloggt + dokumentiert.
Bezug zur Factory
Track 1.1 — pim_audit_log mit Hash-Chain. Append-only. DELETE deaktiviert. Retention: 10 Jahre archive-cold-storage. Audit-UI für Behörden-Anfrage.
Normen — die anerkannten Standards
Nicht direkt verbindlich (Normen sind freiwillig), aber: harmonisierte Normen liefern „Vermutungswirkung" — wer sie einhält, hat den Stand der Technik abgedeckt. NB-Auditoren erwarten sie. Ohne diese Normen: man muss begründen warum nicht.
ISO 13485:2016 — QMS für Medizinprodukte [V] verifiziert # Qualitätsmanagement-System speziell für Medizinprodukte. Pflicht-Vermutung für jeden Hersteller.
Was ist das Thema?
Definiert Anforderungen an ein QMS: Verantwortlichkeiten der Geschäftsleitung, Ressourcenmanagement, Produktrealisierung (Design, Beschaffung, Produktion), Mess- und Verbesserungsprozesse. Härteres Konzept als ISO 9001 — Medizinprodukte-spezifische Risiko- und Rückverfolgbarkeitsanforderungen.
Was wird gefordert?
Strukturierte Prozesse für Design-Control, Lieferanten-Management, Risiko-Management, CAPA (Corrective + Preventive Actions), Schulungs-Nachweise, Sterilisations-Validierung (sofern relevant), Klinische Bewertung-Anbindung.
Beispiele
- Typische SOP-Suite: Backup, Incident, Change, Access, Onboarding, Offboarding, Vendor-Mgmt, Pen-Test, Software-Release, Bug-Fix, Patch-Mgmt, Privileged-Access, Encryption-Key-Rotation, BCP/DR.
- Software-spezifisch: § 4.1.6 fordert Validierung der Computer-Software die im QMS eingesetzt wird.
- Bei Klasse I oft schlanker als bei IIa-III, aber alle Kernprozesse pflicht.
Bezug zur Factory
Track 1.6 (ISMS / SOPs) + Track 1.7 (Toolchain-Validierung). Die Plattform selbst ist „validierte Tool-Chain" gemäß § 4.1.6 [V].
ISO 14971:2019 — Risiko-Management [V] verifiziert # Risikomanagement-Norm für Medizinprodukte. § 7.4 = Risk-Acceptance ist Hersteller-Entscheidung.
Was ist das Thema?
Definiert den kompletten Risikomanagement-Prozess: Hazard-Identifikation, Risk-Assessment (Wahrscheinlichkeit × Schadensschwere), Risk-Control-Maßnahmen, Residual-Risk-Bewertung, Gesamt-Residual-Risk-Acceptance. Aktualisiert lebenslang im Lichte von Vigilanz-Daten.
Was wird gefordert?
§ 7.4 explizit: Bewertung der Akzeptanz des Gesamt-Restrisikos durch den Hersteller (Geschäftsleitung). Diese Entscheidung ist NICHT delegierbar an AI oder externe.
Beispiele
- FMEA-Tabelle pro Tool-Funktion: Was kann schiefgehen? Wie schwer ist der Schaden? Wie wahrscheinlich? Welche Mitigation?
- Beispiel MedReminder: Hazard "Push-Benachrichtigung verpasst" → Mitigation "Doppelversand bei Quittungs-Ausbleiben + In-App-Banner".
- Beispiel Dosis-Kalkulator: Hazard "User gibt falsche Einheit ein" → Mitigation "Einheits-Picker statt Freitext + Plausibilitäts-Check".
Bezug zur Factory
Track 2.3 — AI-Prompt für FMEA-Tabelle + Risk-Acceptance-Sign-Off-UI. AI darf Hazards vorschlagen, Mensch akzeptiert oder überstimmt.
IEC 62304:2006/Amd1:2015 — Software-Lifecycle [V] verifiziert # Software-Lebenszyklus-Norm für Medizinprodukte. Drei Sicherheitsklassen: A (kein Schaden), B (möglicher Schaden), C (möglicher Tod).
Was ist das Thema?
Strukturiert den Software-Lifecycle: Requirements, Architektur, Design, Implementation, Integration + Test, Software-Release, Maintenance, Konfigurations-Management, Problem-Resolution. § 4.3 fordert Bestimmung der Software-Sicherheitsklasse. § 5.1.1: Requirements müssen rückverfolgbar mit Tests verknüpft sein. § 8: SOUP-Behandlung (Software of Unknown Provenance).
Was wird gefordert?
Pro Komponente: Requirements + Architektur + Detail-Design + Implementation + Tests, mit Trace-Matrix. SOUP-Komponenten (npm-Pakete!) müssen separat bewertet werden: Lizenz, Maintainer, CVE-Status, Last-Update.
Beispiele
- Klasse A: reines Anzeige-Tool ohne kritische Funktion → minimaler Lifecycle-Aufwand.
- Klasse B: Symptom-Tracker mit Auswertung → mittlerer Aufwand, alle Lifecycle-Phasen.
- Klasse C: Insulin-Anpasser → voller Lifecycle, jede npm-Dep gerechtfertigt.
- SOUP-Beispiel: react@18.2.0 → Lizenz MIT, Maintainer-Score gut, CVE-Status clean, Last-Update <30 Tage → akzeptiert. axios@0.21.x mit bekanntem CVE → blockiert.
Bezug zur Factory
Track 1.5 (SBOM-Pipeline) + Track 2.5 (Trace-Matrix-Generator) + Track 2.8 (SOUP-Risk-Report pro Spinoff). Auto-Refresh bei jedem Build.
IEC 62366-1:2015 — Usability-Engineering [V] verifiziert # Usability-Engineering für Medizinprodukte. § 5.9 = summative Evaluation mit echten Anwendern.
Was ist das Thema?
Strukturiert den Usability-Prozess: User-Profile, Use-Specifications, User-Interface-Spec, Use-Errors-Identifikation, formative + summative Evaluation. Ziel: Use-Errors die zum Schaden führen können, sind vor Markteinführung identifiziert + mitigiert.
Was wird gefordert?
Summative Evaluation mit „ausreichender" Anzahl realer Anwender (Norm nennt keine harte Zahl, üblich 5-15 [I]). Dokumentierte Use-Errors + Bewertung. Konklusion durch Mensch (nicht AI).
Beispiele
- Pädiater testen Dosis-Kalkulator: 8 Teilnehmer, 4 dokumentierte Use-Errors (alle minor), keine kritischen → Konklusion akzeptabel.
- Patienten testen MedReminder: 5 ältere User + 5 jüngere User. Use-Error "Snooze-Button verwechselt mit Bestätigung" → UI-Anpassung + Re-Test.
- Pflegekräfte testen Vital-Eingabe: 12 Teilnehmer, kein kritischer Use-Error → akzeptiert.
Bezug zur Factory
Factory liefert Use-Spec-Template + Use-Error-Logging. Studienplanung + Auswertung sind Mensch-Pflicht (Mensch-Faktor-Sachv. + Klin.Sachv.).
IEC 81001-5-1:2021 — Cybersecurity im Lifecycle [V] verifiziert # Health-Software-Cybersecurity-Aktivitäten im Produkt-Lifecycle.
Was ist das Thema?
Ergänzt IEC 62304 um Cybersecurity-Aktivitäten: Security-Risk-Assessment, Threat-Modelling, Security-Requirements, Secure-Coding-Guidelines, Vulnerability-Disclosure-Prozess, Patch-Management, Penetration-Testing.
Was wird gefordert?
Security-Aktivitäten parallel zum Software-Lifecycle. Threat-Model muss medizinisch-relevante Bedrohungen abdecken (z.B. Manipulation von Therapie-Empfehlungen, Zugriff auf Patientendaten). Vulnerability-Reporting-Pfad zu Hersteller pflicht.
Beispiele
- Threat-Model MedReminder: Bedrohung "Push-Notification durch Malware umgeleitet" → Mitigation "Server-side Auth + Push-Token-Rotation".
- Threat-Model Dosis-Kalkulator: Bedrohung "Man-in-the-Middle ändert Eingabe in Übertragung" → Mitigation "TLS + HSTS + Eingabe-Hash mit Server-Bestätigung".
- Vulnerability-Pipeline: Snyk + Dependabot blockt high-CVE-Merges nach main.
Bezug zur Factory
Track 1.5 (SBOM + CVE-Pipeline) + Track 1.7 (Toolchain-Validierung). Phase-2-Erweiterung: Threat-Model-Generator pro Spinoff.
ISO 27001:2022 — ISMS [V] verifiziert # Informations-Sicherheits-Management-System. 93 Controls in 4 Themengruppen (in der 2022er Fassung).
Was ist das Thema?
Generelle ISMS-Norm. Nicht medizin-spezifisch, aber: viele Auditoren + Krankenhaus-IT-Compliance-Abteilungen erwarten ISO-27001-Zertifizierung als Voraussetzung für Lieferanten-Status. Korrektur: Anhang A der 2022er Fassung enthält 93 Controls (die ältere 2013er Fassung hatte 114) [V].
Was wird gefordert?
Statement of Applicability (SoA): pro Control wird begründet ob anwendbar + wie umgesetzt. Risk-Treatment-Plan, regelmäßige Reviews, internes Audit, Geschäftsleitungs-Review.
Beispiele
- Control 5.7 (Threat Intelligence) → SoA: anwendbar, Umsetzung via Snyk + Dependabot + monatliche CVE-Reports.
- Control 5.23 (Information security for use of cloud services) → SoA: anwendbar, EU-only-Cloud, Schrems-II-konform.
- Control 8.10 (Information deletion) → SoA: anwendbar, Retention-Policy + automatisierte Löschung nach Aufbewahrungsfrist.
Bezug zur Factory
Track 1.6.2 — SoA-Light für die 93 Controls. Phase 1 macht ISMS-Light, volle Zertifizierung optional in späterer Phase.
ISO/IEC 5962:2021 — SBOM SPDX [V] verifiziert # Software-Bill-of-Materials. SPDX-Format als ISO-Norm.
Was ist das Thema?
Definiert SPDX (Software Package Data Exchange) als standardisiertes SBOM-Format. CycloneDX ist ein alternatives ECMA-standardisiertes Format. Beide sind in der medizinischen Compliance-Welt akzeptiert; FDA empfiehlt SBOMs für Medical-Device-Submissions.
Was wird gefordert?
Pro Build ein SBOM mit allen Dependencies (npm, system-packages), Lizenzen, Versionen, Hashes. Aktualisierung bei jedem Release. Bereitstellung an Auditor + ggf. Endkunden.
Beispiele
- CycloneDX-XML pro Build, output via @cyclonedx/cyclonedx-npm.
- SPDX-JSON parallel für Behörden-Submissions.
- CVE-Anreicherung via Snyk-API + persistiert im Build-Artefakt.
Bezug zur Factory
Track 1.5.1 — CycloneDX-SBOM bei jedem Build, automatisch versioniert + im Audit-Log verlinkt.
Klassifizierungen — was ist mit welchem Aufwand machbar
Die MDR-Klasse ist die zentrale Aufwand-Variable. Hier zeigt jede Klasse: was sie bedeutet, wie der Pfad zur CE aussieht, welche Tools realistisch in welcher Klasse landen.
Klasse I — Selbstdeklaration ohne Notified Body [V] verifiziert # Niedriges Risiko. Hersteller deklariert selbst. ~6-9 Wochen Time-to-CE [S]. Hauptzielgruppe der MDSW-Factory.
Was ist das Thema?
Niedrigste MDR-Klasse. Software trifft KEINE Diagnose- oder Therapie-Entscheidung; sie zeigt Daten an, erinnert, dokumentiert. Self-declaration laut Art. 52 Abs. 7. KEIN Notified Body involviert.
Was wird gefordert?
Vollständige Anhang-II-Doku, Konformitätserklärung, EUDAMED-Registrierung, UDI, PRRC. BASG-Anzeige in AT. Keine NB-Audit. Aber: BASG kann jederzeit nachforderen + inspizieren.
Beispiele
- MedReminder — Patient legt Medikation an, App erinnert via Push.
- SymptomDiary — Patient loggt Symptome (Schmerzskala, Schlafdauer), exportiert PDF für Arzt.
- PainScore-Logger — VAS-Skala 0-10 Tracking, einfache Zeitreihen-Anzeige.
- InjectionSiteRotator — trackt Injektionsstellen, schlägt nächste deterministisch vor.
- Wound-Photo-Tagebuch — Fotos mit Datum/Kommentar, KEIN automatischer Vergleich.
- Trink-Tracker — Tagessoll wird vom Arzt eingestellt, App zählt.
- Pflegedokumentation-Mobile — Vital-Werte-Erfassung am Bett, Sync ins KIS.
- Implantat-Karten-Wallet — Pass-Daten archivieren.
- Praxis-Wartezimmer-Anzeige — öffentliche Anzeige der nächsten Patienten-Nummer.
Bezug zur Factory
~70-80% Factory-Anteil [S]. Ideales Verhältnis Aufwand-zu-Output. Erste Pilot-Tools werden hier entstehen.
Klasse IIa — Notified Body Pflicht, ~6-9 Monate Doku-Aufwand [V] verifiziert # Standardklasse für medizinische Software laut Regel 11. NB-Wartezeit zusätzlich [Q-G].
Was ist das Thema?
Software trifft eine Aussage über den Patientenzustand ODER schlägt Handlung vor — auch wenn nur „Empfehlung". Notified Body prüft das Konformitätsbewertungsverfahren. Stage-1-Off-Site + Stage-2-On-Site-Audit.
Was wird gefordert?
Komplette Tech-Doku + klinische Bewertung mit Lit-Review-Tiefe + ISO-13485-konformes QMS + Notified-Body-Audit + EUDAMED-Registrierung. Auditor-Findings-Resolution typisch 4-8 Wochen [I].
Beispiele
- Symptom-Checker mit Triage-Empfehlung — Symptome → Empfehlung Selbstbehandlung / Hausarzt / Notruf.
- Pädiatrie-Antibiotika-Dosis-Kalkulator — Gewicht + Wirkstoff → Dosis.
- Medikamenten-Interaktions-Checker — mehrere Wirkstoffe → potentielle Interaktionen.
- Risiko-Score-Rechner — Framingham, CHA₂DS₂-VASc, etc.
- Compliance-Erinnerungs-System mit Nicht-Einnahme-Alarm — Pflegekraft-Trigger.
- Anamnese-Fragebogen mit Gewichtung — generiert priorisierte Symptomliste.
- Schmerz-Trend-Analyzer — VAS-Werte über Zeit, Alarm bei Verschlechterung.
Bezug zur Factory
~60-70% Factory-Anteil [S]. Doku-Aufwand stark reduziert durch AI-Drafting. NB-Slot bleibt der Engpass.
Klasse IIb — nur mit klinischer Studie + externem Compliance-Team [V] verifiziert # Falsche Aussage = lebensbedrohlich. Klinische Studie pflicht.
Was ist das Thema?
Höhere Risikoklasse. Software trifft Therapie-Entscheidungen mit potentiell schweren Konsequenzen. Pflicht-klinische-Studie mit Patienten-Kohorte, Ethik-Bewilligung, langfristige Daten.
Was wird gefordert?
Wie IIa, plus eigene klinische Studie (statt Lit-Review-only), plus erweiterte PMS, plus PSUR (Periodic Safety Update Report) jährlich.
Beispiele
- Insulin-Dosis-Anpasser für Typ-1-Diabetiker basierend auf BZ-Verlauf — falsche Dosis = lebensbedrohliche Hypoglykämie.
- Bildanalyse Hautläsion (Melanom-Verdacht) — übersehener Befund = Lebensgefahr.
- EKG-Rhythmus-Erkennung für Patient-Selbstmessung — Vorhofflimmern-Detektion → Antikoagulation-Triage.
- Sepsis-Frühwarnsystem ICU-basiert — Fehler-Detektion = irreversible Gewebsschäden.
Bezug zur Factory
~50-60% Factory-Anteil [S]. Erst nach Phase-1-Stabilisierung + erfolgreichem Klasse-I/IIa-Spinoff.
Klasse III — Out-of-Scope für Rapid-Prototyping [V] verifiziert # Lebensentscheidende Software. 2-3 Jahre + eigenes Geschäftsmodell.
Was ist das Thema?
Höchste Risikoklasse. Software die direkt lebenswichtige Entscheidungen automatisiert oder kritische Hardware steuert. Erfordert eigenes Hersteller-Setup mit Vollzeit-Compliance-Team und tiefgehender klinischer Evidenz.
Was wird gefordert?
Wie IIb, plus Design-Examination-Procedure (Anhang IX Abschnitt 4) oder Type-Examination (Anhang X). Notified Body prüft das Design selbst, nicht nur das QMS.
Beispiele
- Beatmungsgerät-Steuerungssoftware — direkter Eingriff in Lungenfunktion.
- Defibrillator-Algorithmen — Schock-Entscheidung autonom.
- Insulinpumpen-Steuerung — autonomes Dosis-System mit Closed-Loop.
Bezug zur Factory
Out-of-Scope. Eigenes Geschäftsmodell. Falls jemals: separater Setup ab Werk.
Themen — querschnittliche Einzelheiten
Konzepte, Akteure, juristische Spezialthemen die in der medizinischen Software-Entwicklung immer wieder auftauchen.
MDCG 2019-11 — Software-Decision-Tree [V] verifiziert # Guidance der Medical Device Coordination Group. Decision-Tree zur Software-Klassifizierung.
Was ist das Thema?
Offizielle Auslegungs-Guidance der EU-Kommission zur Frage „ist meine Software ein Medizinprodukt?" und „welche Klasse?". Decision-Tree mit Ja/Nein-Fragen führt zur Einstufung. Nicht rechtsverbindlich, aber NB-Auditoren akzeptieren sie als Auslegungs-Maßstab.
Beispiele
- Frage 1: Hat die Software einen medizinischen Zweck (Diagnose, Therapie, Überwachung, Prävention)?
- Frage 2: Verarbeitet sie patienten-spezifische Daten?
- Frage 3: Beeinflusst die Ausgabe medizinische Entscheidungen?
- Klar Klasse-I-Fall: alle "ja" außer der letzten "nicht direkt".
Bezug zur Factory
Decision-Tree wird als Kataloge im Spinoff-Bootstrapper hinterlegt. AI schlägt Klasse vor, PRRC bestätigt final.
EuGH C-311/18 „Schrems II" [V] verifiziert # Urteil vom 16. Juli 2020. Privacy-Shield invalidiert. US-Cloud-Provider sind problematisch.
Was ist das Thema?
Der EuGH stellte fest dass das Privacy-Shield-Abkommen zwischen EU und USA keine ausreichenden Schutzgarantien bot — US-Behörden können auf Daten zugreifen, ohne dass EU-Bürger effektive Rechtsmittel haben (FISA 702, Cloud Act). Folge: Datenübermittlungen in die USA brauchen zusätzliche Standardvertragsklauseln + technische Maßnahmen + Risiko-Folgenabschätzung. Für Gesundheitsdaten praktisch unmöglich rechtssicher.
Beispiele
- AWS in Region eu-central-1 (Frankfurt): rechtlich US-Unternehmen, fällt unter Cloud Act → Konflikt.
- Hetzner / IONOS / OVH / Plesk-AT: EU-souverän, kein Cloud-Act-Konflikt → akzeptabel.
- EU-only-Edge-CDN: muss Edge-Pops in EU haben + keine US-Failover.
Bezug zur Factory
Operator-Direktive 2026-04-28: EU-Region-only als hartes Constraint. Kein US-Hyperscaler. Bevorzugt AT/DE-Hosting.
ELGA / HL7 CDA / FHIR / IHE XDS.b [Q-G] eingangsquelle # AT-Gesundheitswesen-Schnittstellen. ELGA = elektronische Gesundheitsakte.
Was ist das Thema?
ELGA ist die elektronische Gesundheitsakte Österreichs. Sie nutzt international standardisierte Datenformate: HL7 CDA (Clinical Document Architecture) für strukturierte Befunde, FHIR (Fast Healthcare Interoperability Resources) als modernere REST-basierte Variante, IHE XDS.b als Storage-Profile für Dokument-Austausch. Wer ans österreichische Gesundheitsnetz andocken will, braucht ELGA-Zertifizierung der Schnittstellen.
Beispiele
- KIS-Anbindung an ELGA: HL7 CDA Level 3 für Entlassungsbriefe.
- Mobile-App für Arzt-Patient-Datentausch: FHIR-Endpoints, OAuth2-Auth.
- Befund-Distribution: IHE XDS.b mit Affinity Domain Konfiguration.
Bezug zur Factory
Optional. Nicht Voraussetzung für CE. Aber: erschließt Krankenhaus-Markt + ELGA-User-Base. Eigener Adapter-Track wenn Tenant medizinisch + AT-Markt.
§ 121 StGB — Verletzung von Berufsgeheimnissen [Q-G] eingangsquelle # Österreichisches Strafgesetzbuch. Strafbarkeit bei Geheimnisverrat im medizinischen Kontext.
Was ist das Thema?
§ 121 StGB stellt die Verletzung von Berufsgeheimnissen unter Strafe — Personen die kraft Beruf Zugang zu Patienten-Daten haben (Ärzte, Pflegepersonal, IT-Admins in Spitälern) können bei Geheimnisverrat persönlich strafrechtlich belangt werden. Bei Software-Hersteller die Patientendaten verarbeitet kann diese Norm relevant werden, wenn ein Mitarbeiter auf Daten zugreift ohne Berechtigung.
Was wird gefordert?
Für Hersteller: technische + organisatorische Maßnahmen (TOMs nach DSGVO Art. 32) müssen Zugriffe begrenzen. RBAC, Audit-Log, Need-to-Know-Prinzip.
Beispiele
- Admin schaut sich Patient-Daten an, ohne Auftrag → potenziell § 121 StGB + DSGVO-Verletzung.
- Bug erlaubt Cross-Tenant-Lookup → System-seitig § 121-Verstoß möglich.
- Audit-Log fehlt → Nachweis-Lücke bei Vorfall.
Bezug zur Factory
Track 1.1 (Audit-Trail) + Track 1.2 (RBAC granular) sind die technischen Antworten. Org-seitig: SOPs für Privileged-Access (Track 1.6).
EUDAMED + UDI [V] verifiziert # Europäische Medizinprodukte-Datenbank + Unique Device Identifier.
Was ist das Thema?
EUDAMED ist die zentrale EU-Datenbank für Medizinprodukte. Pflicht-Registrierung jedes Produkts mit UDI (Unique Device Identifier). UDI besteht aus DI (Device Identifier, Produkt-spezifisch) + PI (Production Identifier, Charge/Serial). Software-UDI: typisch GS1-AI (12 Stellen) plus Versions-Anhang.
Was wird gefordert?
Vor In-Verkehr-Bringen: UDI generieren, EUDAMED-Account, Produkt anlegen, alle Pflicht-Felder. Aktualisierung bei jeder neuen Version. Public-Lookup ist möglich für Behörden + Marktteilnehmer.
Beispiele
- MedReminder v1.0.0 → UDI 03001234567890-1.0.0 (Beispiel-Format, Real-Format folgt GS1).
- Bei Major-Version-Update neue UDI-Variante mit angepasstem PI.
- EUDAMED-Public-Search: jeder kann nach Hersteller filtern + Produkte einsehen.
Bezug zur Factory
EUDAMED-Registrierung + UDI-Generierung sind Mensch-Schritte (PRRC). Factory liefert die Daten-Vorlage (UDI-Format, Versionsnummer, Klassifizierung).
SOUP — Software of Unknown Provenance [V] verifiziert # IEC-62304-Begriff. Drittsoftware ohne Hersteller-Lifecycle-Doku.
Was ist das Thema?
SOUP = Software-Komponenten die vom Hersteller des Medizinprodukts nicht selbst nach IEC 62304 entwickelt wurden — typisch alle npm-Pakete, OS-Bibliotheken, Browser-Engines. IEC 62304 § 8 fordert: pro SOUP eine Bewertung von Lizenz, Maintainer-Reputation, CVE-Status, funktionale Notwendigkeit, Risiko-Bewertung.
Was wird gefordert?
SOUP-Liste pro Spinoff dokumentiert. Pro Komponente Risiko-Bewertung. Updates kontrolliert (kein Auto-Update von SOUP ohne Re-Bewertung).
Beispiele
- react@18.2.0 — Lizenz MIT, Maintainer Meta + Community, CVE-Status clean → akzeptiert.
- axios@0.21.1 mit Open-Redirect-CVE → entweder updaten auf 0.21.2 + Re-Test oder ersetzen.
- lodash — vollständig genutzt? Falls nur 3 Funktionen: Tree-Shake oder ganz raus.
Bezug zur Factory
Track 2.8 — automatisierter SOUP-Risk-Report pro npm-Dep + Build. CVE-Anreicherung via Snyk/Dependabot. Block-Policy: high CVE blockt main-merge.
Klinische Bewertung — drei Wege [V] verifiziert # Pflicht-Nachweis von klinischer Sicherheit + Leistung. Lit-Review oder eigene Studie oder Plausibilitätsargumentation.
Was ist das Thema?
MDR Art. 61 + Anhang XIV definieren drei Wege: (1) eigene klinische Prüfung mit Patienten-Kohorte (teuer, aufwendig, ethik-pflichtig), (2) Literatur-basierte Bewertung mit Vergleichsprodukt + Stand der Technik (für viele Klasse-IIa-Tools praktikabel), (3) Plausibilitäts-Argumentation für sehr risikoarme Produkte (oft Klasse I).
Was wird gefordert?
Klinischer Bewertungsplan VOR Bewertung. Bewertungsbericht mit nachvollziehbarer Methode + Konklusion durch klinisch-medizinisch ausgebildeten Sachverständigen. Aktualisierung lebenslang im Lichte von Vigilanz-Daten.
Beispiele
- MedReminder Klasse I: Plausibilität + Adherence-Studien aus PubMed → fertig.
- Pädiatrie-Dosis-Kalkulator IIa: Lit-Review zu Dosierungs-Tabellen + Vergleich zu BNFC + Konklusion durch Pädiater → akzeptabel.
- Insulin-Anpasser IIb: eigene 3-Monats-Studie mit 30 Patienten + Ethik-Vote → pflicht.
Bezug zur Factory
Track 2.7 — PubMed-Query-Builder mit AI-Enhancement + Lit-Review-Aggregator. Mensch (Klin.Sachv.) finalisiert immer die Konklusion.
PMS + PSUR — Post-Market Surveillance [V] verifiziert # Lebenslanges Beobachten des eigenen Produkts. PSUR jährlich für Klasse IIb-III, sonst alle 2 Jahre.
Was ist das Thema?
Nach In-Verkehr-Bringen ist der Hersteller verpflichtet, das Produkt aktiv zu überwachen. PMS-Plan beschreibt: welche Daten gesammelt werden (User-Feedback, Bug-Reports, Vigilanz, Lit-Updates), wie sie analysiert werden, wer Konsequenzen zieht. PSUR (Periodic Safety Update Report) fasst diese Daten periodisch zusammen.
Was wird gefordert?
PMS-Plan vor Markteinführung. Datensammlung kontinuierlich. PSUR jährlich (IIb, III) bzw. 2-jährlich (I, IIa). Bei systematischen Trends: Trend-Report an Behörde + ggf. CAPA.
Beispiele
- MedReminder im Markt: User-Feedback-Inbox, monatliche Auswertung von Crash-Reports, jährliche Lit-Search nach neuen Adherence-Studien.
- Dosis-Kalkulator: User-Feedback + Krankenhaus-Pharm-Reports + jährliche Lit-Update.
- CAPA bei systematischem Bug: Wurzelursachen-Analyse + Patch + Re-Validation + Vigilanz-Meldung.
Bezug zur Factory
Track 1.1 (Audit-Trail) liefert die Roh-Daten. Track 2.4 (PSUR-Generator) drafted den jährlichen Bericht. PRRC reviewt + signiert.