Version: 1.1
Stand: September 2026
Status: Teilweise umgesetzt – Direktabsprung (Deep-Link) und Lokation-Feld abgeschlossen und in Betrieb; Statusanzeige und Prefilling offen
| Version | Datum | Session | Akteur | Änderung |
|---|---|---|---|---|
| 1.0 | 2026-09-02 | 68 | Claude Code | Erstversion – Direktabsprung, Lokation-Feld, Prefilling-Konzept auf Basis AP 1.1 S-04/A-03 |
| 1.1 | 2026-09-04 | 71 | Claude Code | Umsetzungsstand nachgetragen (Jörg): Direktabsprung (Deep-Link) und Lokation-Feld abgeschlossen und in Betrieb; O-01/O-02/O-04 erledigt; Abschnitt 6 Priorisierung aktualisiert |
Dieses Dokument konkretisiert AP 2.3 aus dem Projektplan: Erweiterung der ISH-Arbeitsliste um Status-/Fortschrittsanzeige, Ergänzung des Feldes Lokation, direkter Absprung aus der Arbeitsliste in den spezifischen ImplantDok-Fall, sowie Prüfung von Prefilling-Potenzial.
Ausgangspunkt ist Schwachstelle S-04 und Automatisierungspotenzial A-03 aus docs/projekt/ap1_1_prozessanalyse.md: Der Absprung aus der ISH-Arbeitsliste landet heute in der ImplantDok-Fallübersicht, nicht direkt im spezifischen Fall – ein zusätzlicher, vermeidbarer Navigationsschritt für die QS-Fachkräfte. Anders als bei AP 2.1/2.4 (Datenübertragung) und AP 2.5 (Typ-C-Felder) geht es hier nicht um Datenflüsse, sondern um eine reine Workflow-Optimierung innerhalb bestehender, bereits funktionierender Schritte.
Status: ✅ Abgeschlossen und in Betrieb (Session 71).
QS-Fachkraft öffnete die ISH-Arbeitsliste, wählte einen meldepflichtigen Fall aus und sprang nach ImplantDok – landete dort aber in der allgemeinen Fallübersicht und musste den Fall dort erneut suchen oder neu anlegen (AP 1.1, Schritt 7).
Ein Direktabsprung in den spezifischen Fall setzt voraus, dass ISH und ImplantDok denselben Fall eindeutig referenzieren können – strukturell dasselbe Problem wie die Fallverknüpfung bei der Materialschnittstelle (ap2_1_materialschnittstelle.md Abschnitt 3, Priorität 4: NMatV.FALNR → ImplantDok-Fall). Die HL7-ADT-Fallnummer (AP 1.1, Schritte 1–2, produktiv) dient als Schlüssel – im Zuge der Umsetzung implizit bestätigt (O-01 damit erledigt).
Realisiert wurde der Deep-Link-Weg: Die ISH-Arbeitsliste ruft eine ImplantDok-URL mit Fallnummer als Parameter auf, ImplantDok springt direkt zum Fall – wie in Abschnitt 2.3 (ursprüngliche Fassung) als voraussichtlich einfacherer Weg empfohlen. Der Lookup-Weg (ImplantDok öffnet sich allgemein und schlägt den Fall vor) wurde nicht benötigt.
Status: ✅ Abgeschlossen und in Betrieb (Session 71).
QS-Fachkräfte erkennen in der Arbeitsliste jetzt auf einen Blick, aus welchem Standort/OP-Bereich ein Fall stammt, ohne ihn einzeln öffnen zu müssen. Das Feld existierte im ISH-Datenmodell bereits (Standortinformation ist Teil der Fall-/Einrichtungsdaten, die auch per HL7 ADT übertragen werden, AP 1.1 Schritt 2) – es war eine reine Anzeige-Erweiterung der Arbeitsliste, keine neue Datenquelle, und damit unabhängig von den größeren Schnittstellenentscheidungen (K-10) umsetzbar.
Ziel: Sichtbar machen, in welchem Bearbeitungsstand sich ein Fall in der Arbeitsliste befindet (z. B. „noch nicht begonnen" / „in Bearbeitung in ImplantDok" / „gemeldet"), damit QS-Fachkräfte nicht jeden Fall einzeln in ImplantDok prüfen müssen, um den Stand zu erfahren.
Voraussetzung ist ein Rückkanal von ImplantDok zurück zur ISH-Arbeitsliste – heute gibt es nur den bereits produktiven SAP-Report, der Meldebestätigungen abholt (AP 1.1, Schritt 12a), aber keinen laufenden Zwischenstatus. Empfehlung: prüfen, ob derselbe SAP-Report-Mechanismus (oder ein vergleichbarer, häufigerer Abgleich) für einen Zwischenstatus erweiterbar ist, statt einen komplett neuen Rückkanal aufzubauen (O-03).
Der Projektplan nennt „ggf. Prefilling von Feldern aus ISH-Daten" als Prüfpunkt. Das ist inhaltlich kein eigenständiges Thema, sondern eine Konsequenz aus der A/B/C-Feldtyp-Klassifikation aus ap2_5_datenqualitaet.md: Sobald ein Feld über AP 2.4 automatisch aus ISH übertragen wird (Typ A/B), ist es per Definition „vorausgefüllt" – ein separates Prefilling-Konzept nur für die Arbeitsliste wäre doppelte Arbeit. Empfehlung: AP 2.3 verweist auf AP 2.4/2.5 statt ein eigenes Prefilling-Konzept zu entwickeln; „Prefilling" ist damit kein zusätzlicher Umsetzungsschritt, sondern ein Nebeneffekt der dortigen Architektur.
Aktualisiert Session 71: Zwei der vier Bausteine (Direktabsprung, Lokation-Feld) sind inzwischen abgeschlossen und in Betrieb – die ursprüngliche Einschätzung „schneller Erfolg, unabhängig von K-10/SAP-Termin" hat sich damit bestätigt. Offen bleiben Statusanzeige (Abschnitt 4) und Prefilling (Abschnitt 5, ohnehin kein eigenständiger Umsetzungsschritt, siehe dort). Beide hängen weiterhin an keiner der großen Architekturentscheidungen (K-10, SAP-Termin) – Statusanzeige nur an der gezielten Rückfrage zur SAP-Report-Erweiterbarkeit (O-03). Empfehlung unverändert: verbleibende Bausteine parallel zu den größeren Konzepten weiterverfolgen, nicht hinter K-10 zurückstellen.
| # | Thema | Verantwortlich | Referenz |
|---|---|---|---|
| O-01 | IT | ✅ Erledigt (Session 71) – Deep-Link in Betrieb, Fallnummer bestätigt | |
| O-02 | IT / Xaxoa | ✅ Erledigt (Session 71) – Deep-Link umgesetzt, siehe Abschnitt 2.3 | |
| O-03 | SAP-Report-Mechanismus auf Erweiterbarkeit für Zwischenstatus prüfen | IT | ❌ Offen – Abschnitt 4 |
| O-04 | IT | ✅ Erledigt (Session 71) – siehe Abschnitt 3 |