Implantat,
vom Foto
bis zur Meldung.

Sie fotografieren die Verpackungen direkt am Lagerschrank — mit dem Praxis-iPad oder dem eigenen iPhone. Mehrere Implantate auf einem Foto sind kein Problem. Die hauseigene Scan-Plattform dekodiert alle Barcodes parallel (GS1-DataMatrix und EAN/Code128), liest die UDI-DI aus, gleicht sie mit dem Artikelkatalog des Implantateregisters ab und übernimmt LOT, Seriennummer, Ablaufdatum und Hersteller-Code automatisch. iPhone-Standardformat HEIC wird direkt akzeptiert. Mindestens ein Foto pro Wareneingang ist Pflicht — als interner Beleg über die gesetzliche Mindestanforderung hinaus.

Beide Module sind im selben System. Beim Wareneingang werden LOT, Seriennummer und UDI-DI erfasst. Beim OP-Abschluss verbucht das System die zugeordneten Implantate als verbraucht und referenziert sie in der iRegG-Meldung nach §16 — gleiche Charge, gleiche Seriennummer, ein Datensatz. Im OP-Saal scannt niemand mehr Barcodes ab. Sie können den Auslöse-Zeitpunkt wählen: „OP-Abschluss" (sofort beim Beenden des Termins) oder „iRegG-Submit" (erst wenn die Meldung erfolgreich übertragen ist — strenger für Audit-Sicherheit).

Der Tausch-Assistent filtert das Lager nach Größe, Seite und Verfügbarkeit, schlägt passende Ersatz-Implantate vor und führt den Tausch in einem Vorgang durch: Das alte Implantat geht zurück ins Lager (verfügbar) oder in die Retoure mit Grund (Verpackung beschädigt, Hersteller-Rückruf, Ablauf, Lieferanten-Retoure, sonstiger Grund), das neue Implantat wird als verbraucht verbucht. Beide Bewegungen sind bidirektional verlinkt. Die iRegG-Meldung erkennt automatisch die neue Charge — es muss keine alte Meldung manuell storniert werden, das System löst Korrekturmeldungen aus, sobald die Spezifikationsversion das stützt.

Vor dem Speichern prüft das System die Kombination aus Artikel + LOT + Seriennummer gegen den Bestand. Doppelt fotografierte Implantate werden als Hinweis markiert mit dem Vermerk „bereits am [Datum] erfasst" — kein Doppel-Datensatz im Lager und keine Doppel-Meldung an das Implantateregister. Wenn eine Charge nach einer Retoure ins Lager zurückkommt, lässt sie sich als „reaktiviert" zurückholen, mit Audit-Eintrag, wer wann und warum reaktiviert hat.

Sieben granulare Berechtigungen lassen sich pro Mitarbeiter setzen: Lager einsehen, Wareneingang erfassen, Verbrauch buchen, Verbrauch stornieren, Tausch-Assistent nutzen, Foto-Scan und Inventur durchführen. Wir trennen bewusst „Verbrauch buchen" und „Verbrauch stornieren" — wer einbucht, kann nicht alleine eine Implantation rückbuchen. Ein Tausch erfordert zusätzlich die Storno-Berechtigung. Das entspricht dem Vier-Augen-Prinzip für sicherheitsrelevante Bewegungen und ist in jeder Klinik anpassbar — kein vorgegebenes Rollenraster.

Sie fotografieren den Implantatschrank — die Scan-Plattform erkennt alle sichtbaren Codes und gleicht sie mit dem Soll-Bestand ab: was ist bekannt, was ist neu (nachzubuchen), was fehlt. Sie sehen sofort jede Differenz. Jede Inventur-Session bleibt mit ihren Quell-Fotos als eigener Eintrag in der Lager-Historie erhalten — Sie können später nachweisen, wann zuletzt geprüft wurde und welche Implantate zu welchem Zeitpunkt im Schrank lagen. Bei Hersteller-Recalls oder internen Audits ist die Antwort binnen Sekunden auffindbar.

Wenn eine Meldung an das Implantateregister storniert wird, wandern die verknüpften Implantate automatisch zurück aus „verbraucht" nach „verfügbar" — niemand muss manuell umbuchen. Bei einer Korrektur (neue Charge, geänderte Seite, korrigierte Operationscodes) bleibt die alte Meldebestätigung gültig, eine neue wird ausgestellt. Das System hält beide Datenstände in der Lager-Historie nebeneinander, damit der spätere Audit-Prüfer eindeutig nachvollziehen kann, was wann an das Implantateregister gegangen ist.

Die Datenbank selbst verhindert jedes Ändern oder Löschen einer bereits gebuchten Lager-Bewegung — der Schutz ist nicht in der Software, sondern direkt im Datenbank-System verankert. Selbst mit Server-Zugang kann niemand eine Buchung überschreiben. Zusätzlich ist jeder Eintrag mit dem vorigen kryptografisch verkettet — ein nachträgliches Einfügen würde die Kette brechen. Das entspricht der GoBD-Forderung nach unveränderbarer Dokumentation und der iRegG-Pflicht zur lückenlosen Charge-zu-Patient-Nachverfolgung.