Admin-Inhalte
Diese Kapitel gelten für Admin-Konfiguration, Integrationen und Betrieb.
Aktives Kapitel Wofür der Admin da ist
Admin
Wofür der Admin da ist
Der Admin ist die Steuerzentrale für Konfiguration, Integrationen, Freigaben, Monitoring und Diagnose.
Das Admin-Frontend ist kein operativer Arbeitsplatz für Patientenbearbeitung. Es verwaltet, welche Funktionen sichtbar sind, welche Integrationen aktiv sind und ob die Runtime gesund läuft.
Der technische Service-Footer im Admin öffnet dieses Admin-Handbuch. Workspace-Abläufe wie Aufnahme, Fallbearbeitung oder Rezept-Arbeitslisten werden im separaten Workspace-Handbuch beschrieben.
- Admin = Verwaltung und Betrieb.
- Workspace = tägliche Patienten- und Vorgangsbearbeitung.
- Dieses Handbuch enthält keine Workspace-Bedienanleitung.
Layout
Admin-Oberfläche und kompakte Aktionsflächen
Das Admin-Frontend ist nach Hauptbereich, Sidebar-Gruppe und aktivem Funktionspunkt geführt.
Oben wird der Hauptbereich gewählt: Grundlagen, Systemkonfiguration, Integrationen, Monitoring oder Diagnose. Links erscheinen nur die fachlich passenden Gruppen und Funktionspunkte des aktiven Bereichs.
Der Funktionsfokus über der Arbeitsfläche zeigt aktiven Pfad, Titel, Zweck und Fokus. Darunter bleibt nur die aktuell relevante Workbench sichtbar, damit Rollen, Freigaben, Integrationen und Diagnose nicht als gemischte Kartenstrecke ineinanderlaufen.
Formularnahe Admin-Aktionen sparen auf Desktop Höhe: kurze Button-Reihen stehen rechts neben dem Formularblock. Button-Gruppen mit vier oder mehr Aktionen bleiben unter dem Formular, weil sie sonst rechts wieder unnötig Höhe erzeugen würden.
- Hauptnavigation, Sidebar und Funktionsfokus immer gemeinsam lesen.
- Nur der aktive Funktionspunkt ist die aktuelle Arbeitsfläche.
- Rechte Aktionsspalte bedeutet Dichte, nicht versteckte Funktion.
Rechte
Rollen und Freigaben
Rollen, Browserkonten und Freigaben steuern, was im Workspace und Admin sichtbar ist.
Admin-Konten pflegen Benutzer, Rechte und sichtbare Workspace-Funktionen. Wenn eine MFA einen Bereich nicht sieht, wird zuerst die Freigabe geprüft.
Die Ansicht Rollen und Rechte ist zweigeteilt: links bleibt die Rollenliste stehen, rechts wird nur die aktive Rolle mit Zweck, Rechtezählung, Gruppenübersicht und einzelnen Schaltern bearbeitet.
In den Workspace-Freigaben legt der Wähler Gültigkeit fest, ob der globale Standard oder eine einzelne Rolle wie MFA bearbeitet wird. Rollenfreigaben blenden Bereiche nur aus; sie entfernen keine Module.
Die Freigabe steuert Sichtbarkeit. Sie ersetzt keine fachliche Prüfung und keine PVS-Berechtigung.
- Benutzer und Rollen getrennt prüfen.
- Workspace-Funktionen nur gezielt freigeben.
- Letzte Admin-Konten nicht entfernen.
Templates
Kommunikationsbausteine und Templates
Templates liefern kontrollierte Texte für E-Mail, SMS und Dokument-Workflows.
Im Adminbereich können Bausteine gesucht, nach Kanal gefiltert und vollständig eingesehen werden. Die Ansicht fuehrt in drei Schritten durch Auswahl, Textpruefung und Live-Schaltung. Bestehende Systembausteine werden nicht direkt überschrieben; jede Bearbeitung erzeugt eine neue Draft-Alternative.
Neue praxisweite Bausteine werden mit Template-ID, Kanal, Betreff, Text und Kontextschlüsseln angelegt. Sie starten als Draft und werden erst nach Freigabe und Veröffentlichung im Workspace nutzbar.
Nicht-live Versionen können archiviert werden. Veröffentlichte Live-Versionen sind geschützt und werden nicht gelöscht, damit feste Dokument- und Kommunikationsworkflows nicht versehentlich brechen.
Dokumentbenachrichtigungen nutzen feste Template-IDs für Eingang, Bereitstellung und Ablehnung. Leere Dokument-Workflow-Templates dürfen gespeichert werden, lösen aber sichtbar Text fehlt aus.
Ablehnungs-SMS-Bausteine enthalten die Signatur Praxis Reiffert nicht als Standardinhalt. Der Versandpfad hängt sie systemseitig genau einmal an und normalisiert ältere doppelt signierte Bausteine.
Bei SMS muss die fertige Nachricht inklusive Signatur innerhalb von 160 Zeichen bleiben. Längere Texte werden nicht in den Versand eingereiht.
- SMS-Bausteine kurz halten.
- Praxis Reiffert nicht manuell in Ablehnungs-SMS-Bausteine schreiben.
- Entwurf, Freigabe und Live-Schaltung gezielt nutzen.
Integrationen
Integrationen und Kanäle
Hier werden Telefonanlage, Mailversand, Auswertungen und weitere technische Verbindungen kontrolliert.
Placetel-SMS benötigt eine aktive SMS-Konfiguration und sendet nur an gültige deutsche Mobilfunknummern. Festnetz, Ausland, unvollständige Nummern und SMS über 160 Zeichen werden blockiert.
Das Mail-Gateway nutzt ein aktives Standardprofil für SMTP-Versand. Passwörter bleiben verborgen und werden nicht im Klartext angezeigt.
Das Telefonbuch zeigt den Betriebsstatus des gemeinsamen Telefonbuchs: Transport, Rechte, editierbare Kontaktarten mit Begriff, Art und Farbe, Audit-Hinweise, Warteliste und Doppelungsbearbeitung. Der Workspace-Menüpunkt Telefonbuch ist der sichtbare Kontaktarbeitsbereich für Vollsuche, Art-Filter, Anlage, Bearbeitung, bestätigtes Löschen, Zusammenführen und manuelle Vorbefüllung. Bei Ausfall der Telefonanlage während aktivem Transport werden Kontaktanlagen und Änderungen vorgemerkt; Zusammenführen wird nicht vorgemerkt. Bei deaktivierter Schnittstelle bleibt die Warteliste pausiert und POKS startet keinen Providerkontakt.
Placetel stellt aktuell kein geeignetes API-Feld für POKS-Kontaktarten, Farben oder Routing-Tags bereit. POKS nutzt diese Werte deshalb für Anzeige, Vorbelegung und Arbeitslogik; sie dürfen nicht als native Placetel-Tags erwartet werden, bis Placetel die API erweitert.
Contact Discovery wird nicht mehr als eigene Admin-Ansicht bedient. Die Nutzung liegt im Workspace unter Telefonbuch > Branchensuche; Admin bleibt für Telefonbuch, Rechte, Transportstatus und technische Konfiguration zuständig.
Rauka-SIP-Client und Auswertungen haben eigene Betriebszustände. Rückruf-Ziele gehören zum Funktionspunkt Rückruf-Ziele, weil sie die serverseitige Click-to-Call-, Rückruf- und CDR-Nebenstellenauflösung bilden. Vorhandene Ziele können in der Liste geladen, geändert und mit Freigaben gespeichert werden. Freigaben werden über Auswahlfelder für Arbeitsplatz, Teamgruppe, Benutzer oder Rolle gesetzt. Rollenfreigaben gelten breit für alle Konten einer Rolle und passen zu Anmeldung 1-4 sowie Backoffice mit Rolle MFA; Sprechzimmer 1/2 werden als persönliche Nebenstellen über den Benutzer jreiffert freigegeben, nicht über die Rolle Arzt. Der alte POKS-SIP-Trunk ist archiviert; Rauka nutzt eine eigene SIP-Client-Laufzeit.
Ausgehende Placetel-CDRs werden für die Kennzahl Ausgehende Anrufe bereits vor der Zählung gegen aktive Rückruf-Ziele geprüft. Damit zählen auch Gespräche von Anmeldung 1-4, Backoffice und Sprechzimmern, wenn Placetel nur SIP-Kennung, Durchwahl oder Zielkennung liefert.
AL/GDT wurde aus konzeptionellen Gründen aus dem aktiven Core entfernt und spielt in der laufenden Admin-Führung keine Rolle mehr.
Unter Verbindungsprofile können Admin/System externe Transportwege bewusst deaktivieren. Deaktivierte Wege werden nicht als Fehler behandelt: POKS speichert betroffene Nachrichten als skipped und startet keinen Providerkontakt.
- Placetel SMS: +49, deutsche Mobilfunknummer, maximal 160 Zeichen.
- Telefonbuch: Kontaktarten/Farben, gemeinsames Telefonbuch, Doppelungen, Warteliste, kein lokaler Kontaktstamm.
- Contact Discovery: Google-Quelle, manuelle Prüfung, Import nur über Kontaktmodal.
- Placetel-Tags/Farben sind aktuell POKS-Arbeitsmetadaten, solange Placetel kein API-Feld dafür anbietet.
- Mail-Gateway: Profil, Absender, TLS/StartTLS und Betriebsstatus prüfen.
- Verbindungsprofile: Schalter deaktiviert Transportwege temporär ohne Fehlerspam.
- Rauka-SIP-Client und Auswertungen nur als aktive Laufzeitanforderung bewerten, wenn sie fachlich wirklich gebraucht werden.
Betrieb
Monitoring und Runtime
Monitoring erklärt, ob API, Worker, Admin, Web, Datenbank und Jobs stabil laufen.
Der Betriebsstatus prüft PM2-Prozesse, Healthchecks, MariaDB, Warnmeldungen und Empfängerprofile. Warnungen und Fehler werden als Betriebszustand sichtbar.
Rebuild, Status, Prüflauf und PM2-Save gehören auf den Produktionshost. Lokale Arbeitsverzeichnisse werden nicht mit dem Deploy-Skript gestartet.
- Alle vier POKS-Prozesse müssen online sein.
- Der Prüflauf muss failed=0 melden.
- PM2-Save nach erfolgreichen Runtime-Änderungen nicht vergessen.
Diagnose
Diagnose und API-Tests
Diagnose ist für gezielte Fehleranalyse gedacht, nicht für den normalen Praxisablauf.
API-Tests, Funktionsstatus, Betriebszustand und Laufzeitberichte helfen dabei, Integrationsprobleme einzugrenzen, ohne operative Fachansichten zu überladen.
Bei SMS- oder Mail-Problemen zuerst Funktionsstatus, Vorlage, Wartelistenstatus und Worker-Ergebnis prüfen. Persistierte Fehler dürfen keine vollständigen SMS-Texte oder vollen Empfängernummern offenlegen.
- Diagnose gezielt und nachvollziehbar nutzen.
- Keine produktiven Test-SMS ohne bewusste Freigabe auslösen.
- PII in Logs, Jobs und Auditdaten reduziert halten.
FAQ
Häufige Fragen
Warum zeigt das Admin-Handbuch keine Workspace-Bedienung?
Admin und Workspace sind getrennte Frontends. Das Admin-Handbuch erklärt Konfiguration, Integrationen und Betrieb; das Workspace-Handbuch erklärt die tägliche Bearbeitung.
Wo werden SMS-Texte und Signaturen gepflegt?
SMS-Bausteine werden im Template-System gepflegt. Die Ablehnungs-SMS-Signatur Praxis Reiffert wird systemseitig angehängt und gehört nicht manuell in den Baustein.
Warum sind manche Integrationen nicht erforderlich?
Einige Integrationen sind optional oder phasenweise nicht aktiv. Der Prüflauf unterscheidet deshalb zwischen ok, warning, failed und not_required.
Warum soll ich Rebuild nicht lokal starten?
Rebuild, Status, Prüflauf und PM2-Save gehören auf den Produktionshost. Lokal werden Code, Tests und Dokumentation bearbeitet.