Ein Auditor sitzt Ihnen gegenüber. Er bittet um den Prüfdatensatz zu einer Charge, die vor sieben Jahren ausgeliefert wurde.
Die Software, die diesen Datensatz erzeugt hat, läuft längst in einer neueren Version. Der Mitarbeiter, der den Prozess verantwortet hat, ist nicht mehr im Unternehmen. Das Dateiformat von damals öffnet keine Ihrer aktuellen Anwendungen mehr.
Sie haben die Daten. Irgendwo. Auf einem Netzlaufwerk, in einer abgekündigten Datenbank, in einem Backup, das seit Jahren niemand mehr getestet hat.
Die Frage des Auditors ist einfach. Die Antwort ist es nicht.
Genau hier zeigt sich, was Software in der Medizintechnik wirklich verlangt. Das eigentliche Problem ist nicht, eine konforme Anwendung zu entwickeln, sondern über deren gesamte Lebensdauer nachweisen zu können, was sie wann und mit welchem Ergebnis getan hat. Dieser Beitrag zeigt, warum der Nachweis und nicht die Funktion zum entscheidenden Engpass wird, welche Normen den Rahmen setzen und wie revisionssichere Datenhaltung aus einem Compliance-Risiko einen kalkulierbaren Prozess macht.
DAS WICHTIGSTE IN KÜRZE
|
KURZ ZUSAMMENGEFASSTSoftware in der Medizintechnik ist nicht nur eine Entwicklungs-, sondern vor allem eine Nachweisaufgabe. Die regulatorischen Anforderungen verlangen, dass Prozessdaten, Prüfergebnisse und Konfigurationsstände über sehr lange Zeiträume vollständig, unveränderbar und lesbar bleiben. In der Praxis scheitern Audits selten an der Funktion einer Anwendung, sondern an Lücken in der Rückverfolgbarkeit und an Daten, die in abgekündigten Systemen oder veralteten Formaten gefangen sind. Wer die Datenhaltung von der Lebensdauer einzelner Softwaregenerationen entkoppelt, reduziert sein Auditrisiko erheblich. Revisionssichere Archivierung ist dafür der zentrale Baustein. |
Was bedeutet Software in der Medizintechnik?
Software Medizintechnik ist ein doppeldeutiger Begriff und beide Bedeutungen sind regulatorisch relevant.
Zum einen gibt es Software, die selbst ein Medizinprodukt ist oder Teil eines solchen: eingebettete Steuerungen, Diagnoseanwendungen, Software as a Medical Device (SaMD). Zum anderen gibt es Software, die Medizinprodukte herstellt, prüft und dokumentiert: Prozessdatenmanagement, Werkerführung, Qualitätssicherung, Archivierung.
Beide Kategorien teilen dieselbe Grundlast. Sie erzeugen Daten, die als Nachweis dienen. Und für diesen Nachweis gelten strenge Regeln.
Eine Steuerungssoftware in der Produktion ist im engeren Sinne kein Medizinprodukt. Aber die Prüfprotokolle, die sie erstellt, sind Teil der technischen Dokumentation. Fällt diese Dokumentation aus, ist das fertige Produkt nicht mehr belegbar konform unabhängig davon, wie gut die eigentliche Software funktioniert hat.
Software in der Medizintechnik ist damit weniger eine Frage der Funktion als eine Frage des Belegs.
Warum der klassische Entwicklungsfokus zu kurz greift
Die meisten Organisationen investieren ihre Aufmerksamkeit in die Entwicklung. Das ist nachvollziehbar und unvollständig.
Validierung, Verifizierung, Risikoanalyse: Diese Schritte konzentrieren sich auf den Zeitpunkt der Inverkehrbringung. Sie beantworten die Frage, ob eine Software heute korrekt arbeitet. Sie beantworten nicht die Frage, ob sich das in zehn Jahren noch beweisen lässt.
Der regulatorische Lebenszyklus eines Medizinprodukts endet nicht mit der Auslieferung. Er beginnt dort erst.
| Klassischer Fokus | Regulatorische Realität |
|---|---|
| Funktioniert die Software heute? | Lässt sich die Funktion über Jahre belegen? |
| Validierung zum Release-Zeitpunkt | Nachweisführung über den gesamten Produktlebenszyklus |
| Dokumentation als Projektabschluss | Dokumentation als Daueraufgabe |
| Daten leben im aktiven System | Daten müssen Systemwechsel überdauern |
| Verantwortung beim Entwicklungsteam | Verantwortung bei Qualität, Regulatory und Geschäftsführung |
Der Bruch entsteht selten beim Release. Er entsteht später, wenn Systeme abgekündigt, Formate abgelöst und Verantwortliche ersetzt werden, die Nachweispflicht aber unverändert weiterläuft.
Eine Software, die ihre eigene Vergangenheit nicht mehr belegen kann, ist regulatorisch wertlos. Egal wie gut sie heute arbeitet.
- Korbinian Hermann, CSP Intelligence GmbH
Der eigentliche Engpass: Nachweisbarkeit über Jahre
Hier liegt der Kern. Die entscheidende Frage lautet nicht, ob Ihre Software konform ist. Sondern ob Sie diese Konformität in fünf, zehn oder fünfzehn Jahren noch nachweisen können.
Die MDR verlangt, dass die technische Dokumentation für einen langen Zeitraum verfügbar bleibt, in der Regel mindestens zehn Jahre nach dem letzten in Verkehr gebrachten Produkt, bei implantierbaren Produkten mindestens fünfzehn Jahre. Diese Frist überlebt nahezu jede Software-Generation, jeden Hardware-Wechsel und oft auch den Lieferanten der ursprünglichen Anwendung.
Das eigentliche Problem ist nicht die Erzeugung der Daten. Sondern ihre Bewahrung über die Lebensdauer der erzeugenden Systeme hinaus.
In der Praxis bedeutet das: Daten dürfen nicht im aktiven System gefangen sein. Sie müssen unabhängig von der Anwendung lesbar, vollständig und unveränderbar bleiben, die sie ursprünglich erzeugt hat.
Wer diese Trennung nicht vollzieht, koppelt seine Nachweisfähigkeit an die Lebensdauer einzelner Softwareprodukte. Und die ist deutlich kürzer als jede regulatorische Aufbewahrungsfrist.
Wie regulierte Software-Dokumentation konkret funktioniert
Der Rahmen wird durch ein Zusammenspiel mehrerer Normen und Verordnungen gesetzt. Keine davon steht für sich allein.
| Norm / Verordnung | Fokus | Relevanz für Software und Daten |
|---|---|---|
| MDR (EU 2017/745) | Marktzugang von Medizinprodukten | Verlangt technische Dokumentation und deren langjährige Verfügbarkeit |
| IEC 62304 | Software-Lebenszyklus für Medizinprodukte | Definiert Prozesse für Entwicklung, Wartung und Konfigurationsmanagement |
| ISO 13485 | Qualitätsmanagement für Medizinprodukte | Fordert lenkbare, rückverfolgbare Aufzeichnungen |
| ISO 14971 | Risikomanagement | Verknüpft Risiken mit Maßnahmen und deren Nachweis |
| 21 CFR Part 11 (FDA) | Elektronische Aufzeichnungen und Signaturen | Maßstab für Audit-Trail und Datenintegrität (US-Markt) |
Über allen Einzelregeln steht ein gemeinsames Prinzip: Datenintegrität. Ein etablierter Maßstab dafür sind die ALCOA-Kriterien. Daten sollen zuordenbar, lesbar, zeitnah, original und korrekt sein. In der erweiterten Form kommen vollständig, konsistent, dauerhaft und verfügbar hinzu.
Diese Kriterien sind keine Theorie. Sie sind die Liste, an der ein Auditor Ihre Aufzeichnungen prüft.
| Schlechte Praxis | Gute Praxis |
|---|---|
| Daten in geteilten Ordnern, ohne Zugriffsprotokoll | Zugriffe und Änderungen vollständig protokolliert |
| Werte nachträglich überschreibbar | Unveränderbare Aufzeichnung mit Versionshistorie |
| Proprietäres Format ohne Migrationspfad | Langzeitstabile, lesbare Formate |
| Backup ohne Wiederherstellungstest | Geprüfte, dokumentierte Wiederherstellbarkeit |
| Aufbewahrung an Systemlebensdauer gekoppelt | Aufbewahrung systemunabhängig organisiert |
In vier Phasen zur auditfähigen Datenhaltung
Auditfähigkeit entsteht nicht durch ein einzelnes Werkzeug. Sie entsteht durch einen geordneten Prozess.
| Phase | Ziel | Ergebnis |
|---|---|---|
| 1. Bestandsaufnahme | Datenquellen und Nachweispflichten erfassen | Vollständige Übersicht der aufbewahrungspflichtigen Daten |
| 2. Klassifizierung | Fristen, Kritikalität und Formate zuordnen | Klare Regeln, was wie lange und in welcher Form bleibt |
| 3. Überführung | Daten in eine systemunabhängige Archivierung bringen | Manipulationssichere, lesbare Langzeithaltung |
| 4. Betrieb und Audit | Zugriffe, Integrität und Wiederherstellung sichern | Jederzeit belegbarer, prüffähiger Datenbestand |
Phase 1 wird am häufigsten unterschätzt. Viele Organisationen wissen nicht präzise, welche Daten sie überhaupt aufbewahren müssen und welche sie längst nicht mehr lesen können.
Phase 3 ist der eigentliche Hebel. Erst wenn Daten das erzeugende System verlassen und in einer dafür ausgelegten Archivierung liegen, wird die Nachweisfähigkeit von der Software entkoppelt.
Typische Fehler und wie Sie sie vermeiden
Die meisten Probleme sind nicht spektakulär. Sie sind strukturell und genau deshalb gefährlich.
| Fehler | Was passiert | Risiko | Besserer Ansatz |
|---|---|---|---|
| Backup wird mit Archivierung verwechselt | Daten existieren, sind aber veränderbar und unstrukturiert | Kein belastbarer Nachweis im Audit | Revisionssichere, unveränderbare Ablage etablieren |
| Daten bleiben im Quellsystem | Nachweis stirbt mit dem System | Datenverlust bei Migration oder Abkündigung | Frühzeitige Überführung in systemunabhängiges Archiv |
| Proprietäre Formate ohne Migrationspfad | Daten werden mit der Zeit unlesbar | Verfügbar, aber nicht verwertbar | Langzeitstabile Formate und geprüfte Migration |
| Kein durchgängiger Audit-Trail | Änderungen lassen sich nicht zurückverfolgen | Verletzung der Datenintegrität | Lückenlose Protokollierung aller Zugriffe |
| Aufbewahrungsfristen unklar definiert | Daten werden zu früh gelöscht oder unkontrolliert gehortet | Verstoß gegen Nachweispflicht | Klassifizierung mit eindeutigen Fristen |
Der gemeinsame Nenner: Jeder dieser Fehler verschiebt das Problem in die Zukunft. Sichtbar wird er erst im Audit, also genau dann, wenn keine Zeit für Korrekturen mehr bleibt.
Praxisbeispiel: Ein mittelständischer Medizintechnik-Zulieferer
Ein mittelständischer Zulieferer fertigt Komponenten für implantierbare Produkte. Die Nachweispflicht reicht entsprechend weit, fünfzehn Jahre nach der letzten Auslieferung.
Die Ausgangslage war typisch für ein gewachsenes Umfeld.
| Bereich | Ausgangslage |
|---|---|
| Prüfdaten | Verteilt über drei Systeme und mehrere Netzlaufwerke |
| Formate | Teilweise proprietär, mit abgekündigter Software erzeugt |
| Aufbewahrung | An die Lebensdauer der jeweiligen Anwendung gekoppelt |
| Audit-Trail | Nur lückenhaft vorhanden |
| Wiederherstellung | Backups vorhanden, aber nie systematisch getestet |
Im Vorbereitungsaudit kam die entscheidende Frage: Wer hat einen bestimmten Wert wann erfasst, und ist er seither unverändert? Der Zulieferer konnte es nicht zweifelsfrei belegen.
Die Daten waren da. Der Nachweis fehlte.
Nach der Umstellung auf eine systemunabhängige, revisionssichere Archivierung änderte sich das Bild grundlegend.
| Kriterium | Vorher | Nachher |
|---|---|---|
| Auffindbarkeit | Minuten bis Stunden, oft erfolglos | Gezielter Zugriff in Sekunden |
| Integritätsnachweis | Nicht durchgängig belegbar | Lückenloser Audit-Trail |
| Format-Lesbarkeit | Abhängig von Altsoftware | Langzeitstabil und unabhängig |
| Aufbewahrung | An Systeme gekoppelt | Über Systemwechsel hinweg gesichert |
| Audit-Vorbereitung | Wochenlange Sonderaktion | Routinevorgang aus dem Bestand |
Der wichtigste Effekt war nicht die Geschwindigkeit. Es war die Verlässlichkeit. Das Auditrisiko wurde von einer offenen Frage zu einem kontrollierten Prozess.
Die Rolle revisionssicherer Archivierung
Revisionssichere Archivierung ist kein Speicherort. Sie ist eine Eigenschaft des Umgangs mit Daten.
Drei Merkmale machen sie aus. Erstens Unveränderbarkeit: Eine einmal abgelegte Aufzeichnung lässt sich nicht mehr stillschweigend ändern. Zweitens Nachvollziehbarkeit: Jeder Zugriff und jede Version ist protokolliert. Drittens Beständigkeit: Daten bleiben über lange Zeiträume lesbar, unabhängig vom erzeugenden System.
Für Software in der Medizintechnik ist das der fehlende Baustein zwischen Erzeugung und Nachweis.
Die Anwendung erzeugt die Daten. Das Qualitätsmanagement legt fest, was aufbewahrt werden muss. Die Archivierung sorgt dafür, dass dieser Nachweis die Anwendung überlebt.
Ohne diese Trennung bleibt jede Datenhaltung an die Lebensdauer einzelner Systeme gebunden und damit an einen Zeithorizont, der für medizintechnische Nachweispflichten schlicht zu kurz ist.
Selbst-Check: Wie auditfähig ist Ihre Datenhaltung?
Prüfen Sie Ihre aktuelle Situation. Jede Aussage, die Sie nicht eindeutig bejahen können, ist ein potenzielles Audit-Finding.
☐ Wir wissen genau, welche Daten aufbewahrungspflichtig sind und wie lange.
☐ Unsere aufbewahrungspflichtigen Daten liegen unveränderbar vor.
☐ Jeder Zugriff und jede Änderung ist lückenlos protokolliert.
☐ Unsere Daten sind unabhängig vom erzeugenden System lesbar.
☐ Wir haben für proprietäre Formate einen geprüften Migrationspfad.
☐ Unsere Wiederherstellung wird regelmäßig getestet und dokumentiert.
☐ Die Aufbewahrung ist nicht an die Lebensdauer einzelner Anwendungen gekoppelt.
☐ Wir können zu jedem Datensatz Herkunft, Zeitpunkt und Unversehrtheit belegen.
☐ Ein Auditor erhält angeforderte Nachweise ohne Sonderaktion.
☐ Die Verantwortung für die Langzeitarchivierung ist klar zugeordnet.
Auswertung:
- 8 bis 10 bejaht: Ihre Datenhaltung ist auf einem belastbaren Stand. Halten Sie den Prozess durch regelmäßige Prüfungen aufrecht.
- 5 bis 7 bejaht: Es gibt erkennbare Lücken. Priorisieren Sie die offenen Punkte, bevor das nächste Audit ansteht.
- 0 bis 4 bejaht: Ihre Nachweisfähigkeit ist gefährdet. Hier besteht akuter Handlungsbedarf bei der systemunabhängigen Archivierung.
Datenintegrität über den gesamten Lebenszyklus
Genau an dieser Stelle setzt CHRONOS an. CHRONOS ist die Lösung von CSP für die revisionssichere, systemunabhängige Langzeitarchivierung von Prozess- und Qualitätsdaten. Daten werden manipulationssicher abgelegt, mit lückenlosem Audit-Trail versehen und so vorgehalten, dass sie auch nach Jahren und nach dem Wechsel der erzeugenden Systeme vollständig und lesbar bleiben.
Damit entkoppelt CHRONOS Ihre Nachweisfähigkeit von der Lebensdauer einzelner Anwendungen. Was bleibt, ist ein prüffähiger Datenbestand, der die regulatorischen Aufbewahrungsfristen der Medizintechnik trägt.
Mehr dazu unter CHRONOS Datenarchivierung.
Häufig gestellte Fragen
Was ist Software Medizintechnik? Software Medizintechnik bezeichnet einerseits Software, die selbst ein Medizinprodukt ist oder Teil eines solchen ist, und andererseits Software, die Medizinprodukte herstellt, prüft und dokumentiert. Beide erzeugen Daten mit Nachweischarakter und unterliegen strengen regulatorischen Anforderungen an Dokumentation und Aufbewahrung.
Welche Normen sind für Software in der Medizintechnik relevant? Maßgeblich sind unter anderem die MDR (EU 2017/745) für den Marktzugang, die IEC 62304 für den Software-Lebenszyklus, die ISO 13485 für das Qualitätsmanagement und die ISO 14971 für das Risikomanagement. Für den US-Markt kommt 21 CFR Part 11 als Maßstab für elektronische Aufzeichnungen hinzu.
Wie lange müssen Daten in der Medizintechnik aufbewahrt werden? Die technische Dokumentation muss in der Regel mindestens zehn Jahre nach dem letzten in Verkehr gebrachten Produkt verfügbar bleiben, bei implantierbaren Produkten mindestens fünfzehn Jahre. Diese Fristen überdauern nahezu jede Software-Generation, was eine systemunabhängige Archivierung erforderlich macht.
Was bedeutet revisionssichere Archivierung? Revisionssichere Archivierung bedeutet, dass Daten unveränderbar, nachvollziehbar und über lange Zeiträume lesbar abgelegt werden. Jeder Zugriff ist protokolliert, und die Daten bleiben unabhängig vom erzeugenden System verwertbar. Damit unterscheidet sie sich grundlegend von einem reinen Backup.
Reicht ein Backup für die Nachweispflicht aus? Nein. Ein Backup schützt vor Datenverlust, sichert aber weder Unveränderbarkeit noch Audit-Trail noch langfristige Lesbarkeit. Für die Nachweispflicht in der Medizintechnik ist eine revisionssichere Archivierung erforderlich, die diese Eigenschaften garantiert.
Was sind die ALCOA-Prinzipien? ALCOA steht für zuordenbar, lesbar, zeitnah, original und korrekt, die Kernkriterien für Datenintegrität. In der erweiterten Form ALCOA+ kommen vollständig, konsistent, dauerhaft und verfügbar hinzu. Diese Kriterien bilden den Maßstab, an dem Aufzeichnungen in Audits geprüft werden.
Warum scheitern Audits häufiger an der Dokumentation als an der Software? Weil die Funktion einer Software zum Release-Zeitpunkt validiert wird, die Nachweispflicht aber über Jahre weiterläuft. In dieser Zeit werden Systeme abgelöst, Formate veralten und Verantwortliche wechseln. Lücken in der Rückverfolgbarkeit und unlesbare Altdaten sind die häufigsten Befunde.
Wie wird Software-Dokumentation systemunabhängig? Indem die Daten frühzeitig aus dem erzeugenden System in eine dafür ausgelegte Archivierung überführt werden, in langzeitstabilen, lesbaren Formaten und mit durchgängigem Audit-Trail. So bleibt der Nachweis erhalten, auch wenn die ursprüngliche Anwendung abgekündigt wird.
Was sollte ein Unternehmen zuerst tun, um auditfähig zu werden? Der erste Schritt ist eine vollständige Bestandsaufnahme: Welche Daten sind aufbewahrungspflichtig, in welchen Formaten liegen sie vor und wie lange müssen sie verfügbar bleiben? Erst auf dieser Grundlage lassen sich Klassifizierung, Überführung und revisionssicherer Betrieb sinnvoll aufsetzen.
