Version: 1.2
Stand: September 2026
Status: Entwurf – Zielarchitektur REST (Entscheidung Jörg) mit dediziertem /import/implants-Endpunkt (API v0.9.2); technische SAP-Anbindung (direkt oder via ISH) im SAP-Termin zu klären
| Version | Datum | Session | Akteur | Änderung |
|---|---|---|---|---|
| 1.0 | 2026-09-02 | 68 | Claude Code | Erstversion – Architekturempfehlung (Option A/CSV), konsolidierte Klärungsliste für SAP-Termin, Fehlerhandling-/Übergangskonzept |
| 1.1 | 2026-09-04 | 71 | Claude Code | Entscheidung Jörg: Zielarchitektur auf Option B (REST) geändert, CSV (Option A) auf Notnagel/Fallback zurückgestuft. Abschnitt 2.1/2.2 neu gefasst, Abschnitt 6 (Korrektur mapping_materialdaten_sap.md) umgekehrt, neuer Punkt O-07 (SAP-Anbindung direkt vs. via ISH) |
| 1.2 | 2026-09-04 | 71 | Claude Code | Neuer Fund (Jörg): API-Spezifikation v0.9.2 (rest-api-import_v0.9.2.json) zeigt dedizierten /import/implants-Endpunkt inkl. DELETE – Abschnitt 2.1a neu; Löschen/Korrektur-Zeile korrigiert (technisch jetzt möglich); neuer Punkt O-08 (Prozessentscheidung Delete vs. Korrekturprozess) |
Dieses Dokument konkretisiert AP 2.1 aus dem Projektplan: Datenmapping SAP-Schnittstellentabelle → ImplantDok, Berücksichtigung der NMatV-Verlinkung (Abrechnungsrelevanz), Festlegung der Schnittstellenarchitektur, Fehlerhandling/Monitoring sowie Abstimmung mit Logistik 4.0.
Ausgangslage ist AP 1.2 (docs/projekt/ap1_2_materialschnittstelle.md): Die SAP-Schnittstellentabelle ist im Entwicklungssystem angelegt, aber weder produktiv noch vollständig dokumentiert; der vorgelagerte Scannerprozess (Logistik 4.0 / it4process) läuft nur pilotiert in der Frauenklinik ohne SAP-Anbindung. AP 2.1 kann die Zielarchitektur daher nur als Entwurf mit offener Bestätigung liefern – analog zur Situation bei AP 2.5 (Typ-C-Felder), wo ebenfalls ein Rahmen aufgebaut wurde, den ein späterer Fachtermin füllt statt jeder Einzelentscheidung.
Entscheidung Jörg, Session 71: Zielarchitektur für die Materialschnittstelle ist die REST-Schnittstelle (POST /import/path), nicht CSV. CSV MaWi-Import (Option A) wird nicht gestrichen, sondern auf den Status Notnagel/Fallback zurückgestuft – für den Fall, dass die REST-Anbindung technisch nicht rechtzeitig oder nicht vollständig umsetzbar ist, oder für Störungsszenarien (siehe Abschnitt 5.2).
Das löst zugleich einen bestehenden Widerspruch: mapping_materialdaten_sap.md nennt in jeder einzelnen Mapping-Zeile und im Datenfluss-Hinweis bereits durchgängig „REST API" als Xaxoa-Schnittstelle – nur der Header war in Session 68 (vorschnell, auf Basis der Einschätzung in schnittstellenentscheidung.md) auf CSV korrigiert worden. Diese Korrektur wird hiermit zurückgenommen (siehe Abschnitt 6).
| Aspekt | Festlegung |
|---|---|
| Weg | REST API, dedizierter Endpunkt POST /import/implants (Option B) – nicht der generische /import/path wie bei Fall-/Anamnesedaten (AP 2.4); siehe Abschnitt 2.1a |
| Trigger | Event-getrieben, flexibel steuerbar – kein Batch-Fenster nötig (siehe Abschnitt 2.2) |
| Encoding | JSON/UTF-8 |
| Löschen/Korrektur | Technisch über DELETE /import/implants?IKNR=…&KISID=…&OPERATION=… möglich (neu seit API v0.9.2) – Prozessfrage bleibt offen, ob dieser Weg genutzt wird oder Korrekturen weiterhin ausschließlich über den bestehenden Korrekturprozess (AP 1.5) laufen (siehe O-08) |
| Fallback | CSV MaWi-Import (Option A, UNC-Share) bleibt als Notnagel dokumentiert (Aspekte siehe vorherige Version dieses Abschnitts in der Versionshistorie) – kein aktiver Zielweg mehr |
/import/implants-Endpunkt (API v0.9.2)Die bisherige Doku-Grundlage (rest-api-import.yaml, API-Version 0.8.2) kannte nur /import/path (generische Fallinformationen), /import/planning und /import/proms. Jörg hat eine aktuellere Spezifikation nachgereicht: docs/schnittstellen/xaxoa/rest-api-import_v0.9.2.json – API-Version 0.9.2, enthält zusätzlich einen eigenen Endpunkt /import/implants (POST zum Übertragen, DELETE zum Löschen bereits übertragener Implantatdaten), spezifisch für Implantat-/Materialdaten (barcode GS1 oder udi+serial+charge+expiry oder manufacturer+reference+serial+charge+expiry, jeweils mit optionaler localisation R/B/L).
Das ist relevant für AP 2.1 in zwei Punkten:
username/password) nach Registrierung bei Xaxoa – die Spezifikation selbst macht keine Vorgabe, dass der Aufrufer ISH sein muss. Das beantwortet die offene Frage aus Abschnitt 2.1 (O-07) nicht abschließend (das ist eine SAP-seitige Machbarkeitsfrage, keine Xaxoa-seitige Einschränkung), liefert aber ein positives Signal: technisch spricht nichts in der API-Spezifikation gegen einen direkten SAP-Aufruf.Empfehlung: rest-api-import.yaml (0.8.2) als veraltet kennzeichnen, rest-api-import_v0.9.2.json als maßgebliche Quelle für die technische Spezifikation führen (siehe DATEIEN.md).
Offene technische Frage (O-07): schnittstellenentscheidung.md bewertet Option B für Materialdaten bislang mit der Einschränkung „SAP-Daten müssten zuerst nach ISH fließen oder parallel via CSV" – diese Einschätzung basierte auf API-Version 0.8.2 ohne dedizierten Implants-Endpunkt und ist damit zu überprüfen. Ob SAP (direkt oder über eine Middleware) den neuen /import/implants-Endpunkt tatsächlich ansprechen kann, ist die zentrale offene Frage für den nächsten SAP-Termin – nicht mehr ob REST der Zielweg ist, sondern wie SAP technisch andockt.
Mit REST als Zielweg entfällt die Batch-Problematik der bisherigen CSV-Empfehlung: die Übertragung kann event-getrieben erfolgen, statt auf ein nächtliches Zeitfenster zu warten. Die Trigger-Kopplung an den Fallstatus „Implantateregister" (siehe AP 1.1/1.8/2.5) bleibt trotzdem nötig – auch bei Echtzeit-Übertragung muss sichergestellt sein, dass Materialdaten vor Fallstatus-Setzung vorliegen, sonst entstehen IRD-Meldungen ohne Materialdaten. Damit konvergiert AP 2.1 technisch mit AP 2.4 (ISH-Schnittstelle, ebenfalls REST) – beide können dieselbe zentrale Mapping-Tabellen-Komponente und dieselbe Trigger-Logik nutzen (ap2_5_datenqualitaet.md Abschnitt 5), statt getrennter Lösungen für Material- und Anamnese-/OP-Daten. Sollte der Notnagel (CSV) tatsächlich zum Einsatz kommen, gilt für diesen Sonderfall weiterhin das bisherige Batch-Vorgehen (nächtlicher Import + Vollständigkeitsprüfung vor Fallstatus-Setzung).
Das Feld-Mapping ist bereits in docs/schnittstellen/mappings/mapping_materialdaten_sap.md dokumentiert (7 Zeilen: UDI, LOT, Seriennummer, Artikel-ID, Artikelbezeichnung, lfd. Nummer, Verwurf-Kennzeichner, Fallverknüpfung). Alle 7 Zeilen sind ⚠️ offen – jede hängt an derselben Ursache: die kundenspezifische Zusatztabelle ZNIT4_NMATV_ZUS ist noch nicht produktiv, und die konkreten Feldnamen sind bislang Annahmen, keine Bestätigungen.
Diese Konzeptebene dupliziert die Feldtabelle nicht, sondern konsolidiert die zugehörigen Klärungspunkte aus drei bisher getrennten Quellen (AP 1.2 Abschnitt 4, mapping_materialdaten_sap.md Offene Punkte, docs/sap/sap_terminvorbereitung.md Block 1) zu einer Reihenfolge für den nächsten SAP-Termin:
| Priorität | Thema | Warum zuerst |
|---|---|---|
| 1 | Ist IT4REFNR der UDI-Träger? |
Blockiert das wichtigste IRD-Pflichtfeld (UDI); ohne Bestätigung ist keine der übrigen Zeilen verlässlich |
| 2 | Verwurf-Kennzeichner: eigenes Feld in ZNIT4_NMATV_ZUS oder NMatV.STORN wiederverwenden? Zusätzlich jetzt zu klären: Wie bildet der REST-Endpunkt /import/implants einen Verwurf überhaupt ab – das Schema (API v0.9.2) zeigt kein Discard-Flag (siehe mapping_materialdaten_sap.md #11) |
M-Pflichtfeld (siehe Abschnitt 4); Doppelnutzung mit Abrechnung ist ein eigenständiges Risiko (K-03); jetzt zusätzlich technisch ungeklärt auf Xaxoa-Seite |
| 3 | Produktivdatum ZNIT4_NMATV_ZUS |
Bestimmt, ob Punkt 1–2 überhaupt vor Phase-3-Implementierung testbar sind |
| 4 | Fallverknüpfung NMatV.FALNR → ImplantDok-Fall: direktes Feld oder Lookup? |
Ohne diese Verknüpfung ist keine automatische Zuordnung möglich, unabhängig vom übrigen Mapping |
| 5 | Artikel-Identifikationsnummer (IRD-Nr.): in NMatV, Materialstamm (MARA) oder woanders? | Geringere Priorität – betrifft nur ein K-Feld |
| 6 | Xaxoa-Schnittstellenfelder für alle Zeilen bestätigen | Kann erst sinnvoll erfolgen, wenn 1–4 stehen |
Bekannt ist der technische Join: NMatV.LNRLM = ZNIT4_NMATV_ZUS.NMATV_ID. Offen ist die fachliche Seite: NMatV.STORN ist ein Stornokennzeichner aus der Abrechnung. Für den IRD-Verwurf denselben Wert zu verwenden ist naheliegend, birgt aber ein Konfliktrisiko – ein Storno aus Abrechnungsgründen (z. B. Korrekturbuchung) ist nicht zwangsläufig dasselbe Ereignis wie ein tatsächlicher Implantat-Verwurf im OP. Empfehlung: im SAP-Termin explizit klären, ob beide Fälle in der Praxis immer zusammenfallen, oder ob ein separates Verwurf-Feld in ZNIT4_NMATV_ZUS (siehe Priorität 2 oben) zwingend nötig ist, um die IRD-Meldung nicht versehentlich mit Abrechnungsstornos zu vermischen.
Der Korrekturprozess (AP 1.5) hat bereits einen offenen Punkt (O-02): SAP-Report-Fehler sind heute nicht sichtbar. Für AP 2.1 gilt dieselbe Lücke – eine fehlgeschlagene oder unvollständige REST-Übertragung müsste ebenfalls erkennbar sein, bevor ein Fall den Meldestatus erreicht (im Notnagel-Fall CSV zusätzlich ein fehlgeschlagener Import). Empfehlung: keine separate Monitoring-Lösung für die Materialschnittstelle aufbauen, sondern den ohnehin offenen AP-1.5-Punkt (O-02) so erweitern, dass er alle Fehlerquellen (SAP-Report, REST-Übertragung Materialdaten, ggf. CSV-Notnagel) abdeckt – deckt sich mit der analogen Monitoring-Empfehlung in ap2_4_ish_schnittstelle.md Abschnitt 5.1.
Solange V-01–V-03 (siehe Abschnitt 7) nicht produktiv sind, bleibt die manuelle Materialerfassung durch die QS-Fachkräfte in ImplantDok der einzige Weg – das ist heute bereits gelebte Praxis (AP 1.2, Ist-Zustand), aber bislang nicht als eigener Prozess beschrieben (BACKLOG E-05). Für AP 2.1 wird das nicht als vorübergehender Sonderfall behandelt, sondern als regulärer Fallback, der auch nach Einführung der automatischen Schnittstelle bestehen bleiben muss – z. B. wenn die REST-Übertragung an einem Fall vorbeiläuft (Fehler, Ausfall) oder selbst der CSV-Notnagel nicht greift. Formale Beschreibung dieses Prozesses (wer erfasst was, welche Felder mindestens, Eskalation bei Unklarheit) ist damit kein reines Phase-1-Thema mehr, sondern Teil der AP-2.1-Zielarchitektur – E-05 wird entsprechend nicht als vorübergehende, sondern als dauerhafte Anforderung geführt (siehe Abschnitt 8).
mapping_materialdaten_sap.mdDie Session-68-Korrektur wird mit diesem Dokument zurückgenommen: „Xaxoa-Schnittstelle" wird von „CSV MaWi-Import (Option A, vorläufige Arbeitsannahme)" zurück auf „REST API (Option B, Zielarchitektur – Entscheidung Jörg Session 71; CSV MaWi-Import als Notnagel/Fallback)" geändert (siehe Versionshistorie dieses Sheets). Das entspricht wieder dem, was jede einzelne Zeile der Mapping-Tabelle und der Datenfluss-Hinweis in diesem Sheet ohnehin durchgängig ausweisen.
| # | Vorleistung | Projekt | Status |
|---|---|---|---|
| V-01 | Scannerprozess im OP produktiv (alle Kliniken, inkl. SAP-Anbindung) | Logistik 4.0 | ⚠️ Pilot Frauenklinik ohne SAP-Anbindung; Rollout ausstehend |
| V-02 | Übertragung it4process → SAP-Schnittstellentabelle produktiv | Logistik 4.0 | ❌ Nicht umgesetzt |
| V-03 | SAP-Schnittstellentabelle in Produktivsystem verfügbar | Logistik 4.0 / SAP-Team | ⚠️ Nur Entwicklungssystem |
Diese Tabelle bleibt bei AP 1.2 gepflegt (dort die maßgebliche Quelle); hier nur zur Einordnung übernommen, damit die Architekturempfehlung in Abschnitt 2 nicht ohne ihre Voraussetzungen gelesen wird.
| # | Thema | Verantwortlich | Referenz |
|---|---|---|---|
| O-01 | Klärungsreihenfolge aus Abschnitt 3 im nächsten SAP-Termin abarbeiten | SAP-Team / IT | K-02 |
| O-02 | NMatV-Verlinkung / STORN-Konfliktrisiko klären (Abschnitt 4) | SAP-Team | K-03 |
| O-03 | Architekturempfehlung Option B/REST (Abschnitt 2) im SAP-Termin technisch bestätigen | IT / SAP-Team | – |
| O-04 | AP-1.5-Monitoring (O-02 dort) um REST-Übertragungsfehler Materialdaten erweitern (CSV-Notnagel nur falls tatsächlich genutzt) | IT | AP 1.5 |
| O-05 | Übergangslösung Materialdaten formal beschreiben (Abschnitt 5.2) – als dauerhafter Fallback, nicht nur Übergang | Zentrale QS | E-05 |
| O-06 | Trigger-Logik REST-Übertragung mit Trigger „Fallstatus Implantateregister" abstimmen; für Notnagel-Fall (CSV) weiterhin Batch-Rhythmus festlegen | IT | Abschnitt 2.2 |
| O-07 | Klären, ob SAP den neuen /import/implants-Endpunkt direkt ansprechen kann oder der Weg über ISH nötig ist (schnittstellenentscheidung.md Option B: „SAP-Daten müssten zuerst nach ISH fließen" – Einschätzung basierte auf älterer API-Version ohne diesen Endpunkt) |
IT / SAP-Team | Abschnitt 2.1a |
| O-08 | Prozessentscheidung: DELETE /import/implants für Korrekturen nutzen, oder ausschließlich über bestehenden Korrekturprozess (AP 1.5)? |
Zentrale QS / IT | Abschnitt 2.1 |