¶ Projektplan: Meldungen an das Implantateregister Deutschland (IRD)
Version: 1.1
Stand: März 2026
Status: Entwurf
| Version |
Stand |
Session |
Änderung |
| 1.0 |
2026-03-12 |
1–2 |
Erstversion: 6 Phasen, 39 Arbeitspakete, Zeitplan, Risiken, offene Punkte |
| 1.1 |
2026-03-12 |
3–13 |
Vollständige Rekonstruktion aus Transcript: AP 2.4/3.5 (ISH→ImplantDok) ergänzt (L-01/L-02); SAP-Team und klinische Anwender in Projektbeteiligte aufgenommen (L-03/L-04); Risiken Datenschutz und Dokumentationsqualität ergänzt (L-05/L-06); Falldaten-Widerspruch in Kap. 2 behoben (F-05); Operateur/Chirurg in Datentabelle Kap. 3.1 ergänzt (V-01); Kap. 7 verweist auf BACKLOG.md (V-02); Kapitelstruktur Kap. 4–7 korrekt nummeriert (F-04); MMATV durch „neue SAP-Schnittstellentabelle" ersetzt (F-01/F-02); Duplikat AP 2.5 bereinigt (F-03) |
Vollständige, regelkonforme und weitgehend automatisierte Meldung implantatbezogener Eingriffe an das Implantateregister Deutschland (IRD) gemäß den gesetzlichen Anforderungen des IRegG (Implantateregistergesetz, in Kraft seit 01.01.2020) und der IRegBV (Implantateregister-Betriebsverordnung). Oberstes Ziel ist die Vermeidung manueller und doppelter Datenerfassung durch systematische Nutzung vorhandener Datenquellen. Dazu gehören die Analyse und Automatisierung der Datenbereitstellung in ImplantDok, die automatisierte Übertragung von Materialdaten aus dem OP-System (it4process / SAP) sowie die zuverlässige Archivierung der Patienteninformation im i.s.h.med.
| Klinik / Bereich |
Implantattyp |
Besonderheit |
| Frauenklinik |
Brustimplantate |
IRD-Meldepflicht seit 01.07.2024 |
| Orthopädie |
Knie- und Hüftimplantate |
IRD-Meldepflicht seit 01.01.2025; EPRD-Meldung (Lizenz vorhanden, Anmeldung erfolgt, technische Anbindung umgesetzt) |
| Thorax-, Herz- und Gefäßchirurgie (THG) |
Aortenklappen |
IRD-Meldepflicht seit 01.01.2025; zuständig für offene Herz-OPs |
| Innere Medizin 3 – Kardiologie |
Aortenklappen |
IRD-Meldepflicht seit 01.01.2025; zuständig für TAVI (Transkatheter-Aortenklappenimplantation) |
Hinweis EPRD: Die EPRD-Meldung für die Orthopädie erfolgt direkt aus ImplantDok. Lizenz, Anmeldung beim EPRD und technische Anbindung sind bereits abgeschlossen. Im Projekt ist lediglich sicherzustellen, dass die relevanten Materialdaten auch für die EPRD-Meldung vollständig in ImplantDok vorliegen.
| # |
Thema |
Beschreibung |
| 1 |
ISH → ImplantDok Datenschnittstelle |
Automatisierte Übertragung von Anamnese- und OP-Daten aus i.s.h.med an ImplantDok via Medical Cube REST API |
| 2 |
Materialschnittstelle SAP → ImplantDok |
Automatisierte Übertragung der Materialdaten aus der neuen SAP-Schnittstellentabelle an ImplantDok; Berücksichtigung der NMatV-Verlinkung für die Abrechnung |
| 3 |
Archivierungsprozess Patienteninformation |
Empfang der HL7 MDM-Nachricht aus ImplantDok, Ablage im Archiv, Anzeige im i.s.h.med Patientenorganizer |
| 4 |
EPRD-Meldung Orthopädie |
Sicherstellung der vollständigen Datenverfügbarkeit in ImplantDok für die EPRD-Meldung (technische Anbindung bereits produktiv) |
| 5 |
Prozessoptimierung ISH |
Prüfung und ggf. Erweiterung der Arbeitsliste im i.s.h.med |
| 6 |
Schulung und Dokumentation |
Schulung der QS-Fachkräfte und IT-Betrieb in allen betroffenen Kliniken |
| # |
Thema |
Begründung |
| 1 |
Projekt Logistik 4.0 / it4process |
Eigenständiges Projekt; Ergebnisse (Materialdaten in SAP) werden als Vorleistung übernommen |
| 2 |
SAP-Implementierung der Schnittstellentabelle |
Wird im Rahmen von Logistik 4.0 / it4process umgesetzt |
| 3 |
Einführung ImplantDok |
Bereits produktiv; keine Neueinführung |
¶ Systemlandschaft
| Komponente |
System / Lösung |
Einsatzbereich |
Datenarten (Quelle / Ziel) |
| Klinischer Arbeitsplatz |
Oracle Cerner i.s.h.med / ISH |
Klinische Dokumentation, Kodierung |
Quelle: Patientendaten, Falldaten, Anamnesedaten, OP-Daten |
| IRD-Meldesoftware |
ImplantDok (Xaxoa) |
IRD-Meldung, EPRD-Meldung |
Ziel: alle Meldedaten; Quelle: MDM-Nachricht |
| Patientendatenübermittlung |
HL7 ADT (ISH → ImplantDok) |
Schnittstelle |
Patientenstamm- und Bewegungsdaten |
| Materialdatenerfassung OP |
it4process (Scannerlösung) |
OP-Logistik |
Quelle: Implantatdaten (UDI, Charge, Seriennummer) |
| Materialverwaltung |
SAP (neue Schnittstellentabelle; Verlinkung mit NMatV für Abrechnung in Prüfung) |
ERP / Logistik |
Ziel: Materialdaten aus it4process; Quelle: Materialschnittstelle → ImplantDok |
| Archivierung Patienteninformation |
Develop D3 |
Dokumentenarchiv |
Ziel: MDM-Dokumente aus ImplantDok |
| Patientenorganizer |
i.s.h.med Patientenorganizer |
Klinische Ansicht |
Ziel: Anzeige archivierter MDM-Dokumente |
| Endoprothesenregister |
EPRD (Orthopädie) |
Registeranbindung |
Ziel: Implantationsdaten Orthopädie |
| Rolle |
Beschreibung |
| Projektleitung |
Projektverantwortliche/r |
| IT / Systemintegration |
Schnittstellen, ISH-Konfiguration |
| SAP-Team / Materialwirtschaft |
SAP-Schnittstellentabelle, Materiallogistik |
| QS-Fachkräfte |
Fachliche Anforderungen, Testunterstützung, Korrekturprozess |
| Klinische Anwender / Fachlicher Ansprechpartner je Klinik |
Anforderungen je Implantattyp, Abnahmetests |
| Logistik / OP-Management |
Materialdatenerfassung, it4process |
| Archivverantwortliche |
Archivierungsprozess, i.s.h.med Patientenorganizer |
| Datenschutz / IT-Sicherheit |
Datenschutz-Folgenabschätzung, Informationssicherheit |
| Xaxoa (extern) |
ImplantDok-Support und Schnittstellenanpassung |
| Cerner (extern) |
ISH-Support |
¶ 2. Ist-Zustand
- Patientendaten: Automatische Übertragung per HL7 ADT von ISH an ImplantDok.
- Falldaten: Ein Teil der Falldaten (Fallnummer, Aufnahme-/Entlassdatum, Einrichtung) wird automatisch per HL7 ADT übertragen. Weitere Falldaten sowie Anamnesedaten und medizinische OP- und Behandlungsdaten werden manuell durch QS-Fachkräfte direkt in ImplantDok eingegeben.
- Materialdaten: Manuelle Eingabe durch QS-Fachkräfte in ImplantDok.
- Arbeitsliste ISH: Listet meldepflichtige Fälle pro Organisation (Klinik) auf; ermöglicht Absprung zur Fallanlage in ImplantDok. Ein direkter Absprung in die Fallübersicht eines bereits angelegten Falls (zur Erleichterung der täglichen Arbeit der QS-Fachkräfte) ist noch nicht umgesetzt.
- Durchführung der IRD-Meldung: Die QS-Fachkräfte führen die Meldung an das IRD direkt aus ImplantDok heraus durch. ImplantDok übermittelt die Meldung an das IRD und erhält als Rückmeldung eine Meldebestätigung (ID & Hash-Wert).
- Abrechnungsstatus „Implantateregister": Wird automatisch durch den Grouper gesetzt, wenn der Fall vollständig dokumentiert ist. Fälle in diesem Status warten vor Abrechnung auf die IRD-Meldebestätigung (ID & Hash-Wert). Technische Erkennung: IRD-Status „3" am OPS.
- Patienteninformation: ImplantDok erzeugt das Dokument und versendet es per HL7 MDM nach Fallabschluss.
- Archivierung: Das MDM-Dokument soll im Archiv (Develop D3) abgelegt und im i.s.h.med (Patientenorganizer) angezeigt werden.
- Korrekturprozess: Wenn eine Meldung fehlerhaft oder unvollständig ist, muss eine Korrekturmeldung an das IRD übermittelt werden. Der Prozess für die Identifikation fehlerhafter Meldungen, die Korrektur in ImplantDok und die erneute Übermittlung ist noch nicht definiert.
¶ Identifizierte Lücken und Handlungsbedarfe
- Materialdaten werden vollständig manuell erfasst → hoher Aufwand, Fehleranfälligkeit.
- Anamnesedaten und medizinische OP- und Behandlungsdaten werden manuell erfasst, obwohl Teile davon bereits im ISH strukturiert vorliegen → Automatisierungspotenzial nicht genutzt.
- Schnittstelle SAP (neue Schnittstellentabelle) → ImplantDok noch nicht umgesetzt (geplant im Projekt Logistik 4.0 / it4process).
- Archivierungsprozess für HL7 MDM-Nachrichten aus ImplantDok noch nicht produktiv.
- Kein direkter Absprung aus der ISH-Arbeitsliste in die Fallübersicht eines bereits angelegten ImplantDok-Falls.
- Korrekturprozess für fehlerhafte IRD-Meldungen noch nicht definiert.
Die Analyse der Datenquellen und die automatisierte Bereitstellung aller melderelevanten Daten in ImplantDok ist das zentrale und aufwändigste Thema des Projekts. Ziel ist es, manuelle und doppelte Erfassung konsequent zu vermeiden.
Die Anforderungen sind dabei implantattyp-spezifisch – je nach Entität (Brustimplantat, Knie-/Hüftprothese, Aortenklappe) werden unterschiedliche Datenfelder benötigt. Die Analyse muss daher pro Klinik und Implantattyp durchgeführt werden.
| Datenkategorie |
Konkrete Felder (Auswahl) |
Aktuelle Quelle im Haus |
Status Bereitstellung ImplantDok |
| Patientendaten |
Name, Geburtsdatum, Geschlecht, Adresse, Versicherung |
i.s.h.med / HL7 ADT |
✅ Automatisch via ADT |
| Falldaten |
Fallnummer, Aufnahme-/Entlassdatum, Einrichtung |
i.s.h.med / HL7 ADT |
✅ Automatisch via ADT |
| Anamnesedaten |
Gewicht, Größe, BMI |
i.s.h.med (Patientenstamm / Anamnese-Formular) |
❌ Noch nicht übertragen |
|
ASA-Klassifikation |
i.s.h.med (Anästhesiedokumentation) |
❌ Noch nicht übertragen |
|
Vorerkrankungen / Diagnosen |
i.s.h.med (ICD-Kodierung) |
❌ Noch nicht übertragen |
|
Seite des Eingriffs (links/rechts) |
i.s.h.med (OP-Dokumentation) |
❌ Noch nicht übertragen |
|
Weitere entitätsspezifische Felder |
i.s.h.med (je nach Formular) |
⚠️ Klärungsbedarf je Klinik |
| Medizinische OP- & Behandlungsdaten |
OPS-Codes |
i.s.h.med (Kodierung) |
❌ Noch nicht übertragen |
|
OP-Datum, OP-Dauer |
i.s.h.med (OP-Dokumentation) |
❌ Noch nicht übertragen |
|
Revisionseingriff ja/nein |
i.s.h.med (OP-Dokumentation) |
❌ Noch nicht übertragen |
|
Operateur / Chirurg |
i.s.h.med (OP-Dokumentation) |
❌ Noch nicht übertragen |
|
Entlassungsdiagnose (ICD) |
i.s.h.med (Kodierung) |
❌ Noch nicht übertragen |
|
Weitere entitätsspezifische Felder |
i.s.h.med (je nach Klinik/Formular) |
⚠️ Klärungsbedarf je Klinik |
| Materialdaten / Implantate |
UDI, Artikelnummer, Chargennummer, Hersteller |
it4process → SAP (Schnittstellentabelle) |
❌ Schnittstelle in Planung |
- Vorarbeit – ImplantDok Feldliste: Es existiert bereits eine Aufstellung aller Felder in ImplantDok. Diese bildet die Grundlage für die Datenanalyse und ist als Ausgangsdokument für AP 1.6 (Datenanalyse) heranzuziehen.
- Vorarbeit – weitere Datenquellen ermitteln: Neben i.s.h.med und SAP / it4process sind ggf. weitere Systeme als Datenquelle zu ermitteln und zu bewerten (z. B. Anästhesiesystem, PDMS, weitere klinische Dokumentationssysteme). Dies ist explizit Teil von AP 1.6.
- Entitätsspezifische Anforderungen: Die IRD-Meldedatenfelder unterscheiden sich je nach Implantattyp (z. B. Brustimplantat vs. Aortenklappe vs. Endoprothese). Die vollständige Feldliste muss pro Klinik und Implantattyp erhoben und gegen die verfügbaren Datenquellen abgeglichen werden.
- Verteilung der Daten im ISH: Relevante Daten liegen in verschiedenen ISH-Modulen (Patientenstamm, Anamnese-Formulare, Anästhesiedokumentation, OP-Dokumentation, Kodierung). Jede Quelle erfordert eine eigene Schnittstellenbetrachtung.
- Datenqualität und Datenform: Daten können zwar vorhanden sein, aber in falscher Form, unstrukturiert oder an der falschen Stelle vorliegen. Es ist zu unterscheiden ob Daten (A) direkt übernommen, (B) transformiert/gemappt oder (C) erst durch Anpassung des Dokumentationsprozesses erfasst werden müssen.
- Dokumentationsqualität: Automatische Übernahme setzt voraus, dass die Daten vollständig und strukturiert erfasst sind. Wo dies nicht der Fall ist, sind ggf. Dokumentationsprozesse anzupassen.
- Materialdaten: Abhängigkeit vom Projekt Logistik 4.0 / it4process; bis zur Verfügbarkeit der Schnittstelle bleibt manuelle Erfassung als Übergangslösung notwendig.
Die Datenanalyse wird in Phase 1 als eigenes Arbeitspaket (AP 1.6) durchgeführt und bildet die Grundlage für alle Schnittstellenkonzepte in Phase 2. Für jede Klinik und jeden Implantattyp wird ein Daten-Mapping-Sheet erstellt, das folgende Informationen enthält:
- Pflichtfelder und optionale Felder laut IRD-Anforderung
- Aktuelle Datenquelle im Haus (System, Modul, Feld)
- Verfügbarkeit und Qualität der Daten
- Automatisierungspotenzial vs. verbleibende manuelle Eingabe
- Priorisierung der Umsetzung
Ziel: Vollständiges Bild des Ist-Prozesses, Klärung offener Punkte, Definition der Soll-Anforderungen.
Dauer: ca. 4 Wochen
- Aufnahme des vollständigen End-to-End-Prozesses (ADT, manuelle Eingaben, Arbeitsliste, Abrechnungsstatus, MDM, Archiv)
- Identifikation von Schwachstellen und Automatisierungspotenzialen
- Dokumentation als Prozessdiagramm (BPMN oder Swimlane)
- Abstimmung mit SAP-Team zur neuen Schnittstellentabelle (Struktur, Felder, Befüllungslogik)
- Klärung der Verlinkung mit der NMatV für Abrechnungszwecke (Status: in Prüfung)
- Abstimmung mit Logistik 4.0 / it4process-Projekt zu Datenstruktur und Übergabeformat
- Anforderungen an die Materialschnittstelle definieren (Felder, Mapping, Zeitpunkt der Übertragung)
- Klärung: Echtzeit-Übertragung oder Batch?
- Prüfung: Sind alle für die EPRD-Meldung relevanten Materialdaten über die Materialschnittstelle abgedeckt?
- Abstimmung mit Archivverantwortlichen zum MDM-Eingangsverfahren
- Anforderungen für Ablage im Archiv und Darstellung im Patientenorganizer (i.s.h.med) definieren
- Klärung Dokumententyp, Metadaten und Zugriffsrechte
- Klärung Schnittstellenmöglichkeiten von ImplantDok für Materialimport und ISH-Datenimport
- Klärung MDM-Sendeverhalten und Konfigurationsoptionen
- Support-Anforderungen und Zeitplanung abstimmen
- Analyse: Wie werden fehlerhafte oder unvollständige IRD-Meldungen aktuell identifiziert?
- Anforderungen an den Korrekturprozess definieren: Identifikation fehlerhafter Meldungen, Korrektur in ImplantDok, erneute Übermittlung ans IRD
- Festlegung: Die zentrale QS ist für die Durchführung des Korrekturprozesses verantwortlich
- Klärung mit Xaxoa: Welche Funktionen bietet ImplantDok für Korrekturmeldungen?
- Klärung: Rückmeldungen / Fehlercodes des IRD und deren Verarbeitung in ImplantDok
- Abstimmung mit QS-Fachkräften zum gewünschten Arbeitsablauf
- Erhebung aller IRD-Pflicht- und optionalen Felder pro Klinik und Implantattyp (Brustimplantat, Knie-/Hüftprothese, Aortenklappe offen, TAVI) – Ausgangsbasis: vorhandene ImplantDok-Feldliste
- Abgleich mit verfügbaren Datenquellen (i.s.h.med, SAP, it4process, weitere Systeme)
- Erstellung von Daten-Mapping-Sheets in zwei Ebenen:
- Basis-Sheet (gemeinsam): Felder die für alle Implantattypen gleich sind (z. B. Patientendaten, Falldaten, Grunddaten zur OP) – bildet die stabile Grundlage für zukünftige Erweiterungen
- Entitäts-Sheet (spezifisch): Felder die je Implantattyp unterschiedlich sind – je ein Sheet pro Entität (Brustimplantat, Knie-/Hüftprothese, Aortenklappe offen, TAVI)
- Bewertung je Feld nach Aufgabentyp: A = direkt übernehmen, B = transformieren / mappen, C = Dokumentationsprozess anpassen
- Identifikation von Lücken: fehlende Felder, unstrukturierte Dokumentation, Qualitätsmängel
- Priorisierung der Schnittstellenentwicklung auf Basis der Analyseergebnisse
- Abstimmung mit QS-Fachkräften und klinischem Personal je Klinik
- Zusammenfassung aller Anforderungen (fachlich & technisch)
- Abnahme durch Fachbereich und IT
Ziel: Technische und fachliche Konzepte für alle Schnittstellen und Prozessanpassungen.
Dauer: ca. 4 Wochen
- Datenmapping: Felder der neuen SAP-Schnittstellentabelle auf ImplantDok-Felder
- Berücksichtigung der Verlinkung mit NMatV (Abrechnungsrelevanz)
- Schnittstellenarchitektur definieren (Middleware, Direktanbindung, Dateiformat)
- Fehlerhandling und Monitoring konzipieren
- Abstimmung mit Logistik 4.0 / it4process sicherstellen
- MDM-Nachrichtenstruktur und Dokumentenformat spezifizieren
- Ablagelogik im Archiv (Develop D3) definieren (Ordnerstruktur, Metadaten, Versionierung)
- Einbindung in den Patientenorganizer (i.s.h.med) spezifizieren
- Hinweis: Zugriffsrechte und Berechtigungen werden über i.s.h.med geregelt – kein separates Zugriffskonzept erforderlich
- Prüfung: Erweiterung der Arbeitsliste um Status- und Fortschrittsanzeige
- Ergänzung des Feldes Lokation (Standort / OP-Bereich) in der Arbeitsliste zur besseren Orientierung der QS-Fachkräfte
- Konzept für direkten Absprung aus der Arbeitsliste in die Fallübersicht eines bereits angelegten ImplantDok-Falls
- Optimierungspotenziale bei manuellem Eingabeaufwand für QS-Fachkräfte prüfen
- ggf. Prefilling von Feldern aus ISH-Daten konzipieren
- Technische Spezifikation der Schnittstelle für Anamnese- und OP-Daten (ISH → ImplantDok)
- Übertragungsprotokoll: Medical Cube REST API (Xaxoa), Endpunkt
POST /import/path; JSON, UTF-8; Authentifizierung per API-Key (Header) oder Basic Auth; Patientenidentifikation per KIS-Fallnummer + Mandanten-ID oder IKNR
- Mapping-Logik auf Basis der Daten-Mapping-Sheets (Basis-Sheet + Entitäts-Sheets aus AP 1.6); konkrete Feldnamen je Entität aus Xaxoa Info-Page (abhängig von K-04)
- Berücksichtigung Aufgabentyp A (direkt übernehmen) und B (transformieren / mappen)
- Trigger-Logik definieren: Wann wird die Übertragung ausgelöst? (z. B. bei OP-Abschluss im ISH)
- Fehlerhandling und Monitoring konzipieren
- Abstimmung mit Cerner / ISH-Team und Xaxoa
- Identifikation aller Typ-C-Felder (müssen erst strukturiert im ISH erfasst werden) aus AP 1.6
- Konzeption der notwendigen Anpassungen an Dokumentationsprozessen und ISH-Formularen je Klinik
- Abstimmung mit klinischem Personal und QS-Fachkräften: Wer erfasst was, wann und wo?
- Priorisierung: Welche Felder sind Pflicht für die IRD-Meldung, welche optional?
- Definition von Qualitätskriterien für die Datenerfassung
- Abgleich: Welche Datenfelder benötigt das EPRD, welche liefert die Materialschnittstelle?
- Lückenanalyse und ggf. Ergänzung fehlender Felder im Datenmapping
- Kein Konzeptionsbedarf für technische Anbindung (bereits produktiv)
- Zusammenführung aller Teilkonzepte
- Review durch alle Beteiligten
- Freigabe für Implementierung
Ziel: Technische Umsetzung aller Schnittstellen und Prozessanpassungen.
Dauer: ca. 8–12 Wochen
- Entwicklung / Konfiguration der Schnittstelle (neue SAP-Schnittstellentabelle → ImplantDok) gemäß Konzept
- Datenmapping implementieren
- Fehlerhandling und Logging implementieren
- Abstimmung mit Logistik 4.0 / it4process-Projekt (abhängige Liefergegenstände)
- Konfiguration MDM-Empfang im Archiv
- Implementierung Ablagelogik
- Integration in i.s.h.med Patientenorganizer
- Berechtigungen einrichten
- Erweiterungen der Arbeitsliste (gemäß Konzept AP 2.3), inkl. Lokation-Feld und direktem Absprung in Fallübersicht
- ggf. Prefilling-Logik oder weitere Konfigurationen
- Schnittstellenkonfiguration für Materialimport (mit Xaxoa)
- MDM-Sendekonfiguration prüfen und ggf. anpassen
- Entwicklung / Konfiguration der Schnittstelle gemäß Konzept AP 2.4
- Implementierung Mapping-Logik (Typ A und B Felder) auf Basis der Daten-Mapping-Sheets
- Fehlerhandling und Logging implementieren
- Abstimmung mit Cerner / ISH-Team und Xaxoa
- Anpassung ISH-Formulare und Dokumentationsprozesse je Klinik gemäß Konzept AP 2.5 (Typ-C-Felder)
- Abstimmung und Einführung neuer Erfassungsprozesse mit klinischem Personal und QS-Fachkräften
- Sicherstellung der Datenqualität durch Pflichtfeldprüfungen und Validierungsregeln wo möglich
- Umsetzung des definierten Korrekturprozesses in ImplantDok (gemäß Konzept aus AP 1.5)
- Konfiguration der Verarbeitung von IRD-Rückmeldungen und Fehlercodes
- Einrichtung der Zuständigkeit der zentralen QS für Korrekturmeldungen
- Test des Korrekturworkflows mit Xaxoa
- Umsetzung der Lückenanalyse aus AP 2.6: fehlende EPRD-Felder im Datenmapping ergänzen
- Abstimmung mit Fachbereich Orthopädie und ggf. Xaxoa
- Validierung der vollständigen Datenverfügbarkeit für EPRD-Meldungen
Ziel: Sicherstellung der korrekten Funktion aller Komponenten und des Gesamtprozesses.
Dauer: ca. 4 Wochen
- Testplan erstellen (Unit Tests, Integrationstests, End-to-End-Tests)
- Testfälle für alle Arbeitspakete definieren
- Testumgebung bereitstellen
- Testdaten aus SAP-Schnittstellentabelle in ImplantDok übertragen
- Vollständigkeit und Korrektheit des Mappings prüfen
- Fehlerszenarien testen (fehlende Daten, ungültige Formate)
- MDM-Nachricht aus ImplantDok senden und Archivablage prüfen
- Anzeige der Patienteninformation im i.s.h.med Patientenorganizer prüfen
- Metadaten und Dokumentenzuordnung validieren
- Anzeige der meldepflichtigen Fälle pro Klinik prüfen
- Lokation-Feld und Statusanzeige validieren
- Direkten Absprung in Fallübersicht ImplantDok testen
- Absprung zur Fallanlage testen
- Übertragung aller Typ-A- und Typ-B-Felder aus ISH nach ImplantDok prüfen
- Mapping-Logik je Entität (Brustimplantat, Knie-/Hüftprothese, Aortenklappe, TAVI) validieren
- Fehlerszenarien testen (fehlende Daten, ungültige Formate, Verbindungsabbruch)
- Vollständigkeit auf Basis der Daten-Mapping-Sheets prüfen
- Prüfung ob Typ-C-Felder in den angepassten ISH-Formularen korrekt erfasst werden
- Validierungsregeln und Pflichtfeldprüfungen testen
- Fachlicher Abnahmetest mit klinischem Personal je Klinik
- Testszenarien für fehlerhafte und unvollständige IRD-Meldungen durchspielen
- Korrektur in ImplantDok und erneute Übermittlung ans IRD testen
- Verarbeitung von IRD-Fehlercodes und Rückmeldungen prüfen
- Abnahme durch zentrale QS
- Vollständigkeit aller EPRD-relevanten Felder in ImplantDok prüfen
- EPRD-Meldung aus ImplantDok testweise durchführen und Rückmeldung validieren
- Abnahme durch Fachbereich Orthopädie
- Vollständigen IRD-Meldeprozess von Fallanlage bis Meldebestätigung und Archivierung testen
- Abrechnungsstatus „Implantateregister" und IRD-Status „3" am OPS prüfen
- Fachlicher Abnahmetest durch QS-Fachkräfte
- Dokumentation und Behebung aller Testergebnisse
- Retest nach Korrekturen
Ziel: Anwender auf den neuen Prozess vorbereiten, Go-Live sicherstellen.
Dauer: ca. 2–3 Wochen
- Anwenderhandbuch für QS-Fachkräfte (ImplantDok, Materialschnittstelle)
- Kurzanleitung Arbeitsliste ISH und Patientenorganizer
- Schulungsunterlagen für IT / Betrieb (Monitoring, Fehlerhandling)
- Schulung QS-Fachkräfte (ImplantDok, Korrekturprozess, neue Schnittstellen)
- Schulung IT-Betrieb (Monitoring, Fehlerhandling, Betriebsprozesse)
- Schulung OP-Logistik (Materialdatenerfassung it4process, soweit relevant)
- Schulung klinisches Personal je Klinik (angepasste ISH-Formulare und neue Dokumentationsprozesse aus AP 3.6)
- Go-Live-Datum festlegen und kommunizieren
- Rollback-Plan definieren
- Hypercare-Phase planen (intensiver Support nach Go-Live)
- Benutzerverwaltung: Prozess für Anlage, Änderung und Deaktivierung von Accounts in ImplantDok – inkl. Regelung zur kontinuierlichen Pflege (z. B. bei Personalwechsel)
- Update- und Patch-Management: ImplantDok, Schnittstellen, abhängige Systeme – inkl. Prozess für regelmäßige und außerplanmäßige Updates
- Monitoring: Überwachung der Schnittstellen (SAP → ImplantDok, ISH → ImplantDok, MDM → Archiv / Develop D3)
- Fehlerbehandlung im laufenden Betrieb: Eskalationswege, Verantwortlichkeiten
- Kontakte und SLAs: Xaxoa, Cerner, SAP-Team, Develop D3
- Datensicherung und Wiederherstellung
- Hinweis: Das Betriebskonzept beschreibt nicht nur die Einrichtung zum Go-Live, sondern auch die laufende Betriebspflege – Prozesse müssen dauerhaft gelebt und bei Änderungen aktualisiert werden
- Abnahme des Betriebskonzepts vor Go-Live
Ziel: Produktivbetrieb aufnehmen und stabilisieren.
Dauer: ca. 4 Wochen Hypercare, danach Regelbetrieb
- Produktivschaltung aller Schnittstellen und Prozesse
- Begleitung durch IT und Fachbereich
- Intensives Monitoring aller Schnittstellen:
- SAP → ImplantDok (Materialdaten)
- ISH → ImplantDok (Anamnese- und OP-Daten)
- ImplantDok → Archiv / Develop D3 (MDM)
- Überwachung des Korrekturprozesses: Werden fehlerhafte Meldungen korrekt identifiziert und durch die zentrale QS bearbeitet?
- Schnelle Reaktion auf Störungen und Fehler
- Regelmäßige Abstimmungsrunden (täglich/wöchentlich)
- Projektdokumentation vervollständigen
- Lessons Learned Workshop
- Übergabe an Regelbetrieb / Support
- Projektabschlussbericht
Der Zeitplan basiert auf folgenden Annahmen. Weichen die tatsächlichen Rahmenbedingungen ab, sind die Schätzungen entsprechend anzupassen.
| # |
Annahme |
Auswirkung bei Abweichung |
| 1 |
Projektstart und Ressourcenzusage erfolgen zeitnah |
Verzögerung des Gesamtzeitplans |
| 2 |
SAP-Schnittstellentabelle (Logistik 4.0) ist bis Phase 3 verfügbar |
AP 3.1 kann nicht termingerecht umgesetzt werden; manuelle Materialerfassung als Übergangslösung |
| 3 |
Xaxoa stellt Schnittstellenunterstützung zeitnah bereit |
Verzögerung von AP 2.4, 3.5 |
| 4 |
ISH-Team (Cerner) steht für Anpassungen zur Verfügung |
Verzögerung von AP 3.3, 3.5 |
| 5 |
Testumgebung ist rechtzeitig vor Phase 4 verfügbar |
Verzögerung der Testphase |
| 6 |
Klinisches Personal steht für Abstimmungen und Tests zur Verfügung |
Verzögerung von AP 1.6, 4.5, 4.6 |
| Phase |
Inhalt |
Geschätzte Dauer |
| Phase 1 |
Analyse & Anforderungserhebung |
ca. 4 Wochen |
| Phase 2 |
Konzeption & Design |
ca. 4 Wochen |
| Phase 3 |
Implementierung |
ca. 8–12 Wochen |
| Phase 4 |
Test & Qualitätssicherung |
ca. 4 Wochen |
| Phase 5 |
Schulung & Go-Live-Vorbereitung |
ca. 2–3 Wochen |
| Phase 6 |
Go-Live & Hypercare |
ca. 4 Wochen |
| Gesamt |
|
ca. 6–7 Monate |
Hinweis: Phasen können teilweise parallel laufen (z. B. Schulungsunterlagen während der Testphase). Ein detaillierter Meilensteinplan mit konkreten Terminen wird nach Projektstart und Ressourcenzusage erstellt (E-02).
| Abhängigkeit |
Beschreibung |
| Projekt Logistik 4.0 / it4process |
Bereitstellung der Materialdaten in SAP (neue Schnittstellentabelle) ist Voraussetzung für AP 3.1 |
| Xaxoa (ImplantDok) |
Schnittstellenunterstützung für Materialimport, ISH-Datenimport und MDM-Konfiguration |
| SAP-Team |
Klärung und Zugang zur neuen SAP-Schnittstellentabelle |
| Cerner / ISH-Team |
Anpassungen Arbeitsliste, ISH-Formulare, Patientenorganizer |
Wichtiger Hinweis: Unabhängig vom Projektfortschritt besteht bereits heute eine gesetzliche Meldepflicht gemäß IRegG für alle betroffenen Kliniken. Die Meldungen sind Voraussetzung für die Abrechnung der Fälle – Fälle im Abrechnungsstatus „Implantateregister" warten auf die IRD-Meldebestätigung (ID & Hash-Wert) und können ohne diese nicht abgerechnet werden. Der laufende Meldebetrieb muss daher während der gesamten Projektlaufzeit sichergestellt sein, auch wenn Prozesse noch nicht vollständig optimiert sind.
Hinweis: Die nachfolgende Risikoliste erhebt keinen Anspruch auf Vollständigkeit. Risiken können sich während der Projektlaufzeit verschieben, in ihrer Bedeutung verändern oder neue Risiken können hinzukommen. Die Liste ist regelmäßig – mindestens zu Beginn jeder Phase – zu überprüfen und zu aktualisieren.
| Risiko |
Eintrittswahrscheinlichkeit |
Auswirkung |
Maßnahme |
| Verzögerung Logistik 4.0 / it4process |
Mittel |
Hoch |
Frühzeitige Abstimmung; manuelle Materialerfassung als Übergangslösung |
| Ungeklärte Verlinkung NMatV ↔ SAP-Schnittstellentabelle |
Mittel |
Mittel |
Klärungsstatus eng verfolgen; frühzeitig in AP 1.2 abschließen |
| Eingeschränkter ImplantDok-Schnittstellensupport durch Xaxoa |
Niedrig |
Hoch |
Frühzeitige Kontaktaufnahme, SLA klären |
| Technische Inkompatibilität MDM → Archiv / Develop D3 |
Niedrig |
Mittel |
Frühzeitiger Proof-of-Concept in Phase 2 |
| Ressourcenengpässe bei QS-Fachkräften und klinischem Personal (Tests, Schulung) |
Mittel |
Mittel |
Frühzeitige Kapazitätsplanung; Termine je Klinik frühzeitig blocken |
| Unvollständige oder unstrukturierte Dokumentation im ISH |
Mittel |
Hoch |
Frühzeitige Analyse in AP 1.6; ggf. Dokumentationsprozesse vor Schnittstellenentwicklung anpassen |
| Datenschutz und Informationssicherheit bei Datenübertragungen |
Mittel |
Hoch |
Datenschutzbeauftragten und IT-Sicherheit frühzeitig einbinden; Datenschutz-Folgenabschätzung prüfen |
| Verzögerung oder Änderungen seitens Cerner / ISH-Team |
Mittel |
Mittel |
Frühzeitige Abstimmung; ISH-Anpassungen priorisieren |
| Laufende Meldepflicht gefährdet Abrechnung bei Prozessunterbrechungen |
Mittel |
Hoch |
Betrieb sicherstellen; Eskalationsprozess für Meldeausfälle definieren |
Detaillierte Klärungsbedarfe und geplante Ergänzungen werden im BACKLOG.md verwaltet.
| # |
Thema |
Priorität |
Abhängigkeit |
| 1 |
SAP-Schnittstellentabelle: Felder, Struktur und Befüllungslogik abstimmen (K-02) |
Hoch |
AP 1.2 |
| 1a |
NMatV-Verlinkung klären (K-03) |
Mittel |
AP 1.2 |
| 2 |
Abstimmung mit Logistik 4.0 / it4process: Zeitplan und Liefergegenstände klären |
Hoch |
AP 3.1 |
| 3 |
Xaxoa: Termin für Abstimmung zu Schnittstellen und Stammdaten vereinbaren (AP 1.4) |
Hoch |
AP 1.4 |
| 4 |
Archiv-Ansprechpartner benennen (K-06) |
Mittel |
AP 1.3 |
| 5 |
Ressourcen QS-Fachkräfte und klinisches Personal je Klinik für AP 1.6 und Abnahmetests sichern |
Mittel |
AP 1.6 |
| 6 |
EPRD-Lückenanalyse (AP 2.6): Vollständigkeit der Materialdaten für EPRD-Meldung prüfen |
Mittel |
AP 2.6 |
| 7 |
Datenschutzbeauftragten und IT-Sicherheit frühzeitig einbinden |
Hoch |
Phase 1 |
| 8 |
Schnittstellenentscheidung ISH → ImplantDok finalisieren (K-10) |
Hoch |
AP 2.4 |