Version: 1.2
Stand: September 2026
Status: Entwurf – Architekturempfehlung vorläufig, finale Entscheidung bei IT (K-10); konvergiert jetzt mit AP 2.1 auf REST
| Version | Datum | Session | Akteur | Änderung |
|---|---|---|---|---|
| 1.0 | 2026-09-02 | 68 | Claude Code | Erstversion – Architekturempfehlung (Option B/REST), Mapping-Logik, Trigger, Patientenidentifikation, Fehlerhandling |
| 1.1 | 2026-09-04 | 71 | Claude Code | Abschnitt 2.1/5.1 nachgezogen: ap2_1_materialschnittstelle.md empfiehlt jetzt ebenfalls REST (Entscheidung Jörg) statt CSV – „jede Quelle eigener Weg"-Begründung durch Konvergenz auf REST ersetzt |
| 1.2 | 2026-09-04 | 72 | Claude Code | Abschnitt 5: Verweis auf PoC Feldtypenkonzept (projekte/poc_feldtypenkonzept/) als konkrete Anwendung der Mapping-Komponente ergänzt |
Dieses Dokument konkretisiert AP 2.4 aus dem Projektplan: technische Spezifikation der Schnittstelle für Anamnese- und OP-Daten (ISH → ImplantDok), Mapping-Logik für Aufgabentyp A (direkt übernehmen) und B (transformieren), Trigger-Logik, Fehlerhandling/Monitoring, Abstimmung mit Cerner/ISH-Team und Xaxoa.
Abgrenzung zu AP 2.5: AP 2.4 behandelt ausschließlich Typ-A/B-Felder (automatisch übertragbar). Typ-C-Felder (manuelle Erfassung, Prozessanpassung) sind Gegenstand von ap2_5_datenqualitaet.md – dort auch die Trigger-Kopplung, die beide APs betrifft (siehe Abschnitt 4).
Abhängigkeit K-10: Der Übertragungsweg für ISH-Daten ist die zentrale offene Architekturentscheidung des Projekts (docs/projekt/entscheidungen.md E-10-01, Entscheidungsträger IT). AP 2.4 kann diese Entscheidung nicht vorwegnehmen, aber – analog zu AP 2.1, wo für die SAP-Seite bereits eine Arbeitsannahme getroffen wurde – eine begründete Empfehlung als Arbeitsgrundlage liefern, damit Mapping-Logik, Trigger und Fehlerhandling schon jetzt spezifiziert werden können, statt komplett auf K-10 zu warten.
docs/projekt/schnittstellenentscheidung.md bewertet für ISH-Daten die Optionen B (REST API POST /import/path) und C (HL7 ADT A08 + Z-Segmente). Die dortige Einzelbewertung stuft Option B bereits als „technisch sauberster Weg für KIS-Daten" ein; Option C wird durch die schmale aktuelle ADT-Ausprägung (nur PID/PV1/IN1/ZBE, keine Z-Segmente) und ungeklärten Erweiterungsaufwand gebremst.
Korrektur Session 71: Bis Session 70 galt hier die Begründung „jede Datenquelle nutzt den Weg, der zu ihrem führenden System passt" – CSV für SAP, REST für ISH, analog zum „Kombinationsszenario" in schnittstellenentscheidung.md. Jörg hat die Zielarchitektur für Materialdaten in ap2_1_materialschnittstelle.md Abschnitt 2.1 inzwischen auf REST umgestellt (CSV nur noch Notnagel) – beide Datenquellen konvergieren damit auf denselben Übertragungsweg (REST), statt je einen eigenen zu nutzen. Das verstärkt die Empfehlung in diesem Abschnitt eher, als sie zu schwächen: eine zentrale Mapping-Tabellen-Komponente und Trigger-Logik (ap2_5_datenqualitaet.md Abschnitt 5) kann jetzt für Material- und ISH-Daten gemeinsam genutzt werden, statt für zwei getrennte Transportwege ausgelegt zu sein. Diese Empfehlung bleibt eine Arbeitsannahme für AP 2.4, keine Vorwegnahme von K-10 – die Entscheidung bleibt bei der IT.
| Aspekt | Festlegung (vorläufig) |
|---|---|
| Weg | REST API POST /import/path (Option B) |
| Auslösung | Event-getrieben (siehe Trigger-Logik, Abschnitt 4) |
| Format | JSON, UTF-8 |
| Authentifizierung | API-Key (Header) oder Basic Auth – finale Wahl mit Xaxoa/IT (O-01) |
| Patientenidentifikation | KIS-Fallnummer + Mandanten-ID, alternativ IKNR (siehe Abschnitt 3) |
Falls sich im Rahmen von K-10 zeigt, dass ISH-seitiger REST-Entwicklungsaufwand zu hoch ist, bleibt Option C (Z-Segment-Erweiterung) die dokumentierte Alternative. Die in diesem Dokument beschriebene Mapping-Logik (Abschnitt 3) und die Aufgabentyp-Klassifikation sind wegunabhängig – bei einem Wechsel auf Option C ändert sich nur die Transportschicht, nicht die inhaltliche Spezifikation.
Die HL7-ADT-Anbindung für Patienten-/Falldaten ist bereits produktiv (AP 1.1, Schritte 1–2) und referenziert Fälle über die KIS-Fallnummer. Für AP 2.4 wird dieselbe Fallnummer als primärer Schlüssel übernommen – konsistent mit der Fallnummer, die auch in AP 2.1 (SAP-Fallverknüpfung) und AP 2.3 (Arbeitslisten-Direktabsprung) als Schlüssel angenommen wird. Alle drei APs hängen damit an derselben offenen Bestätigung: Ist die ADT-Fallnummer wirklich durchgängig identisch mit dem ImplantDok-internen Fallschlüssel? (O-02 – wird nur einmal geklärt, gilt dann für AP 2.1/2.3/2.4 gemeinsam.)
Mandanten-ID oder IKNR dienen als Zusatzkriterium bei Mehrfachbetrieb (z. B. mehrere Standorte/Institutionskennzeichen) – laut Projektplan als Alternative vorgesehen, konkrete Notwendigkeit für dieses Projekt noch nicht geprüft (O-03).
Wie in ap2_5_datenqualitaet.md Abschnitt 5 bereits empfohlen: Der bestehende Trigger „Fallstatus Implantateregister" im ISH (AP 1.1/1.8) löst heute die manuelle QS-Bearbeitung aus. Für die automatische Schnittstelle gilt dieselbe Kopplung, aber umgekehrt: Die Übertragung darf erst erfolgen, wenn
ap2_5_datenqualitaet.md) bereits erfasst sind – sonst entsteht eine unvollständige IRD-Meldung, obwohl die technische Übertragung erfolgreich war.Diese Reihenfolge ist eine Prozessvoraussetzung, keine rein technische Frage – sie muss mit den Dokumentationsfachkräften und der zentralen QS abgestimmt werden (O-04), nicht nur mit IT.
Grundlage sind die Daten-Mapping-Sheets aus AP 1.6 (Basis-Sheet mapping_allgemein.md + Entitäts-Sheets je Implantattyp). AP 2.4 spezifiziert nicht erneut jedes einzelne Feld – das bleibt Aufgabe der Mapping-Sheets – sondern die technische Umsetzung der Mapping-Logik als Komponente:
ap2_5_datenqualitaet.md Abschnitt 5 empfohlen: eine zentrale, konfigurierbare Mapping-Tabellen-Komponente statt Schlüssel-Transformationen im Schnittstellencode hart zu kodieren – Wiederverwendung über alle vier Implantattypen (die dort dokumentierten Schlüssel-Gruppen für Endoprothese sind das erste konkrete Beispiel für diesen Bedarf; bei Aortenklappe/Brustimplantat kommen weitere hinzu).Konkrete Anwendung: projekte/poc_feldtypenkonzept/poc_feldtypenkonzept.md (Session 72) zeigt diese
Komponente exemplarisch an den Feldern aus mapping_allgemein.md + Hüft-/Knieendoprothese – Teil A/B des
dortigen PoC.
Analog zur Empfehlung aus ap2_1_materialschnittstelle.md Abschnitt 5.1: keine separate Monitoring-Lösung für die ISH-Schnittstelle aufbauen, sondern den bereits offenen Punkt aus AP 1.5 (O-02, SAP-Report-Fehler heute nicht sichtbar) um eine weitere Fehlerquelle erweitern – REST-Übertragungsfehler ISH → ImplantDok. Damit entsteht eine Monitoring-Komponente für SAP-Report, REST-Übertragung Materialdaten und REST-Übertragung ISH-Daten (zwei davon jetzt technisch derselbe Übertragungsweg, siehe Abschnitt 2.1) statt mehrerer einzelner Lösungen – zuzüglich CSV-Notnagel-Monitoring, falls dieser tatsächlich zum Einsatz kommt.
Speziell für REST gilt: Bei einem fehlgeschlagenen synchronen Aufruf (Option B ist laut schnittstellenentscheidung.md synchron) muss der Fall erkennbar in einem „nicht übertragen"-Zustand bleiben, damit er nicht stillschweigend ohne Anamnese-/OP-Daten gemeldet wird – dieselbe Grundregel wie die Trigger-Kopplung in Abschnitt 4.
| # | Thema | Verantwortlich | Referenz |
|---|---|---|---|
| O-01 | Authentifizierungsverfahren (API-Key vs. Basic Auth) mit Xaxoa/IT final klären | IT / Xaxoa | Abschnitt 2.1 |
| O-02 | Bestätigen: ADT-Fallnummer = ImplantDok-Fallschlüssel? (gemeinsam mit AP 2.1/2.3 zu klären, nicht dreifach) | IT | Abschnitt 3 |
| O-03 | Notwendigkeit Mandanten-ID/IKNR als Zusatzkriterium prüfen | IT | Abschnitt 3 |
| O-04 | Prozessvoraussetzung „Trigger erst nach Pflicht-Typ-C-Feldern" mit Dokumentationsfachkräften/zentraler QS abstimmen | Zentrale QS / IT | Abschnitt 4 |
| O-05 | Zentrale Mapping-Tabellen-Komponente technisch spezifizieren (Schnittmenge mit AP 2.1/2.5) | IT | Abschnitt 5 |
| O-06 | AP-1.5-Monitoring (O-02) um REST-Übertragungsfehler erweitern | IT | Abschnitt 6 |
| O-07 | K-10-Entscheidung selbst – liegt bei IT, nicht durch dieses Dokument vorwegnehmbar | IT | entscheidungen.md E-10-01 |