Das Core-System bildet die Laufzeitumgebung. Es steuert die Initialisierung aller Module.
Fehler-Management: Das System erzwingt display_errors = 0, unterdrückt aber gleichzeitig selektiv E_DEPRECATED und E_NOTICE, um den Betrieb in medizinischen Umgebungen stabil zu halten, auch wenn Drittanbieter-Plugins Warnungen ausgeben.
Modul-Lader (Hot-Loading): Die Funktion prüft den hs_mod_-Präfix in der wp_options-Tabelle. Nur wenn der Wert exakt auf '1' steht, wird die entsprechende PHP-Datei via include_once geladen. Dies minimiert den RAM-Verbrauch pro Seitenaufruf massiv.
Auto-Login Mechanik: Beim Aufruf von hs_demo_login=1 wird die WordPress-Authentifizierung umgangen. Das System sucht den User besucher, setzt via wp_clear_auth_cookie() alle alten Sitzungen zurück und erzwingt via wp_set_auth_cookie() eine neue Session mit der Rolle hs_inhaber.
Ein proaktives Sicherheitsmodul zur Überwachung unbefugter Backend-Zugriffe.
Trigger: Hängt am admin_init-Hook.
Logik: Er prüft die Capability manage_options. Falls ein User (insbesondere der Demo-User) versucht, /wp-admin aufzurufen, ohne diese Rechte zu besitzen, greift die Umleitung auf die home_url().
Data-Logging: Der Vorfall wird nicht nur blockiert, sondern in einem serialisierten Array in hs_security_logs gespeichert. Dabei werden der REMOTE_ADDR, der Zeitstempel und die versuchte URL archiviert.
Zeitsteuerung: Das System nutzt den Unix-Zeitstempel in der Meta-Spalte hs_demo_last_reset.
Lösch-Prozess: Die Funktion hs_reset_demo_data führt einen db->query für jede Tabelle aus. Wichtig: Die Löschung erfolgt mandantenspezifisch über die praxis_id. Es werden alle Records in hs_personal, hs_stempeluhr, hs_aufgaben etc. gelöscht, deren ID mit der ID des Besuchers übereinstimmt.
Dieses Modul ist die Datenquelle für fast alle anderen Module.
Datenbank-Schema: Tabelle hs_personal. Wichtigste Spalten: pin (String), rolle (Enum), limit_check.
PIN-Verschlüsselung: Die PIN wird im Klartext für den Inhaber angezeigt, aber bei der Verifizierung in anderen Modulen über einen SQL-Abgleich (WHERE pin = %s AND id = %d) validiert.
Limit-Check-Logik: Bevor das System den INSERT-Befehl für einen neuen Mitarbeiter ausführt, wird eine COUNT(*)-Abfrage auf die Tabelle hs_personal gemacht. Dieser Wert wird mit der globalen Option hs_limit_personalakten verglichen. Ist der Wert erreicht, wird der „Speichern“-Button via CSS/JS deaktiviert und die PHP-Verarbeitung bei einem manipulierten POST-Request hart abgebrochen.
Die Stempeluhr arbeitet zustandsorientiert (State Machine).
Zustands-Abfrage: Beim Laden des Shortcodes
wird für den gewählten Mitarbeiter der letzte Record in hs_stempeluhr gesucht, bei dem check_out den Wert NULL hat.
Aktions-Trigger: * Findet das System keinen offenen Record -> Status: Abwesend. Es wird nur der Button "Kommen" gerendert.
Findet das System einen Record ohne check_out -> Status: Anwesend. Das System berechnet via JavaScript die Differenz zwischen dem check_in Zeitstempel und der aktuellen Browserzeit für den Live-Counter.
Pausen-Logik: Pausen werden als eigene Zeilen mit dem Typ Pause markiert, um die Netto-Arbeitszeit am Ende des Monats präzise berechnen zu können.
Dieses Modul nutzt eine komplexe E-Mail-Chain-Logik.
Antrags-Prozess: Ein Eintrag in hs_urlaub_v81 wird mit dem Status beantragt erstellt. Gleichzeitig wird ein eindeutiger 64-stelliger token generiert.
Mail-Level 1 (Praxismanager): Eine E-Mail wird an die hinterlegte Adresse des PMs gesendet. Der Link enthält den Token. Klickt der PM, wird der Status in der DB auf geprueft gesetzt.
Mail-Level 2 (Inhaber): Erst wenn der Status geprueft ist, triggert das System die zweite Mail an den Inhaber.
Finalisierung: Klickt der Inhaber auf "Genehmigen", wird ein SQL-Trigger ausgelöst, der die Differenz der Arbeitstage (unter Ausschluss von Wochenenden) berechnet und den Wert vom Feld resturlaub in der Tabelle hs_personal abzieht.
Frontend-Sync: Der Planer baut eine Matrix aus 31 Tagen auf. Für jede Zelle führt das Modul eine SQL-Abfrage aus: SELECT status FROM hs_urlaub_v81 WHERE personal_id = %d AND %s BETWEEN beginn AND ende.
Logik: Wenn der Status genehmigt zurückgeliefert wird, wird das input-Feld durch ein div mit der CSS-Klasse status-vacation ersetzt. Eine manuelle Schichtplanung für diesen Tag ist somit technisch unmöglich.
Dies ist ein System zur kontrollierten Dokumentenlenkung.
Revisions-Logik: Die Tabelle hs_qm_dokumente hält nur die aktuelle Version. Die Tabelle hs_qm_revisionen speichert Kopien der alten Datensätze.
Der "Force-Read" Trigger: Bei jedem Upload einer neuen PDF-Datei wird die Spalte version inkrementiert. Gleichzeitig führt das System einen DELETE-Befehl auf hs_qm_signs für diese dokument_id aus.
Konsequenz: Alle Mitarbeiter-Häkchen verschwinden sofort. In der Mitarbeiter-Ansicht erscheint das Dokument wieder als "Ungelesen" (rote Markierung), bis die neue Version erneut per PIN quittiert wurde.
Anonymisierungs-Technik: Beim Speichern einer CIRS-Meldung wird bewusst auf die Speicherung der user_id verzichtet. In der Datenbank wird nur die praxis_id für die Zuordnung gespeichert.
Ishikawa-Tool: Im Backend können Management-User eine Meldung bearbeiten. Das UI bietet Radio-Buttons für die 5 Hauptursachen (Mensch, Maschine, Material, Methode, Mitwelt). Die Auswahl wird als String in ursache_typ gespeichert und dient als Basis für den jährlichen Qualitätsbericht.
Dieses Modul dient der rechtssicheren Verwaltung des medizinischen Inventars gemäß MPBetreibV.
Datenbank-Struktur: Nutzt zwei Tabellen: hs_geraete_master (Stammdaten) und hs_geraete_buch (Wartungshistorie).
STK/MTK-Ampelsystem (Technische Logik):
Das System führt beim Laden der Übersicht eine PHP-Iteration durch alle Geräte aus.
Berechnung: strtotime($geraet->naechste_pruefung) - time().
Liegt das Ergebnis unter 0 -> CSS-Klasse red (Überfällig).
Liegt das Ergebnis zwischen 0 und 2.592.000 (30 Tage) -> CSS-Klasse yellow (Bald fällig).
Digitale Einweisungs-Signatur:
Technik: Nutzt eine HTML5 Canvas-API (signature_pad).
Speicherung: Beim Absenden wird die Zeichnung in einen Base64-kodierten String umgewandelt und direkt in das Longtext-Feld signatur der Tabelle hs_geraete_master geschrieben. Es wird keine physische Bilddatei erzeugt, was die Datenbank-Backups schlank hält.
Abgangs-Trigger: Jedes Mal, wenn ein Material entnommen wird (📉), führt das System zwei SQL-Aktionen in einer Transaktion aus:
UPDATE hs_bestands_liste SET bestand = bestand - %d WHERE id = %d
INSERT INTO hs_bestands_abgang (Dokumentation von Datum, Menge, Mitarbeiter und optionalem Patienten-Bezug).
Kühlschrank-Logik:
Das Modul validiert Eingaben gegen einen festen Korridor (Standard: 2°C bis 8°C).
Eingaben außerhalb dieses Bereichs werden in der Tabelle hs_kuehlschrank_log markiert und triggern einen indicator bg-crit im Chef-Dashboard.
Fristen-Algorithmus:
Das System berechnet das Warn-Datum basierend auf dem intervall (in Monaten).
SQL-Logik: DATE_SUB(vertrags_ende, INTERVAL kündigungsfrist MONTH).
Automatisierte Wiedervorlage: Verträge, die das Warn-Datum erreicht haben, werden automatisch in der Ansicht ganz oben fixiert und farblich hervorgehoben.
QR-Code-Generierung: Das System erzeugt keine statischen Bilder, sondern nutzt eine dynamische URL-Struktur: [Site-URL]/?print_qr=[Raumname]&px=[Praxis-ID]. Dies ermöglicht den Druck von Reinigungs-Checklisten für jeden Raum.
Reinigungs-Matrix:
Jede Reinigung wird in hs_hy_matrix gespeichert.
Beim Aufruf eines Raumes prüft das System den letzten Zeitstempel für diesen spezifischen Raum. Ist die Differenz zur aktuellen Zeit größer als das definierte Reinigungsintervall, schaltet der Status auf „Reinigung erforderlich“.
Externe Reinigung: Es existiert eine globale Option hs_hy_ext_pin, die einen Zugang für externes Reinigungspersonal ermöglicht, ohne dass diese als Mitarbeiter in der Personalverwaltung angelegt sein müssen.
Rechtssicherheit: Gemäß den Vorgaben der Berufsgenossenschaften (DGUV) dürfen Einträge im Verbandbuch nach der Erstellung nicht mehr verändert werden.
Technische Sperre: Das Modul erlaubt für Mitarbeiter-Rollen nur den INSERT-Befehl. Die UPDATE-Funktion ist im Code für alle Rollen außer dem Administrator deaktiviert, um die Revisionssicherheit der Unfallerfassung zu garantieren.
Dieses Modul fungiert als digitales Kassenbuch.
Aggregations-Logik:
Das System berechnet den Kontostand nicht durch einen statischen Wert, sondern durch Echtzeit-Summierung: SELECT SUM(CASE WHEN typ='Einnahme' THEN betrag ELSE -betrag END) FROM hs_buchhaltung.
Beleg-Verknüpfung:
Hochgeladene Belege werden in den WordPress-Uploads gespeichert. Die URL zum Bild wird in der Spalte beleg_url gespeichert.
Das Modul erzwingt beim Speichern eine Mitarbeiter-ID (mitarbeiter_id), sodass jede Ausgabe (z.B. Praxiseinkauf) einem Verantwortlichen zugeordnet ist.
Dieses Modul fungiert als Kommunikationsschicht zwischen der cloudbasierten HealthSuite und der lokalen Praxisverwaltungssoftware (PVS).
Technische Konfiguration:
Die Einstellungen werden im serialisierten Array hs_pvs_settings gespeichert (Provider, Ziel-IP, Protokoll wie GDT oder HL7).
Live-Terminal Mechanik:
Das System simuliert den Handshake-Prozess über ein CSS-animiertes Log-Terminal.
Handshake-Logik: Beim Laden wird ein PHP-Ping-Befehl (sofern vom Server erlaubt) oder ein fsockopen-Aufruf an die hinterlegte IP und den Port abgesetzt. Ein Status-Code 200/Open setzt das System auf "Aktiv".
Sicherheits-Layer: * Nutzt wp_verify_nonce für alle Konfigurationsänderungen, um CSRF-Angriffe auf die sensiblen Netzwerkeinstellungen zu verhindern.
Ein spezialisierter Workflow für die papierlose Patientenaufnahme auf Tablets.
Kiosk-Modus: Das Modul nutzt ein CSS-Layout, das die WordPress-Navigation und Footer komplett unterdrückt, um eine ablenkungsfreie Umgebung zu schaffen.
Formular-Workflow:
Template-Mapping: PDFs werden in der Tabelle hs_pat_templates hinterlegt.
Signatur-Erfassung: Wie im Gerätemanager wird ein HTML5-Canvas genutzt. Die Unterschrift wird als Base64-String in hs_pat_signatures gespeichert.
PDF-Verschmelzung & Versand:
Das System triggert beim Abschluss eine wp_mail-Funktion.
Hintergrund-Prozess: Die Formulardaten (Name, Geburtsdatum) und die Signatur werden mit dem Original-PDF zu einem neuen Dokument "verschmolzen" (Mapping via Koordinaten im PHP-Backend) und als Anhang an den konfigurierten Import-Ordner der Praxissoftware gesendet.
Ein dynamisches System zur Aufgabenverwaltung mit Fokus auf Fristen.
Daten-Scope: Alle Abfragen sind strikt durch WHERE praxis_id = %d isoliert.
Status-Management:
Nutzt drei vordefinierte Status-Kerne: Offen, In Arbeit, Erledigt.
Ein Klick auf den Aktions-Button löst einen template_redirect aus, der via wpdb->update den Status-String in der Spalte status der Tabelle hs_aufgaben ändert.
Überfälligkeits-Check:
PHP prüft beim Rendern jeder Kachel: if (strtotime($task->faellig_am) < time() && $task->status !== 'Erledigt').
Ergebnis: Die Kachel erhält die CSS-Klasse task-overdue (roter Indikator).
Strukturierte Erfassung und Archivierung von Sitzungsprotokollen.
Speicher-Logik: Protokolle landen in hs_protokolle. Felder wie teilnehmer und aufgaben werden als Textblöcke gespeichert, um eine einfache Volltextsuche im Archiv zu ermöglichen.
Druck-Engine: Das Modul enthält ein spezielles Media-Query @print, das alle UI-Elemente (Sidebar, Buttons, Footer) ausblendet und eine saubere A4-Dokumentation für den physischen Aushang generiert.
Gruppierungs-Algorithmus: Das System führt ein SELECT mit ORDER BY kategorie aus. Im Frontend wird ein PHP-Zustandsspeicher genutzt: Sobald sich beim Durchlaufen der Liste der Wert kategorie ändert, wird automatisch eine neue Zwischenüberschrift (Kategorie-Trenner) eingefügt.
Copy-to-Clipboard: Integrierte JavaScript-Funktion, die den inhalt der Vorlage direkt in den Zwischenspeicher des Nutzers legt, um die Übernahme in Arztbriefe zu beschleunigen.
Digitales Schulungssystem für gesetzliche Pflichtunterweisungen.
Datenbank-Tandem: Nutzt hs_u_themen (Inhalte) und hs_u_logs (Ergebnisse).
Quiz-Engine:
Quizfragen werden als JSON-Objekt (Frage, Optionen, Index der richtigen Antwort) gespeichert.
Validierung: Beim Absenden vergleicht eine foreach-Schleife in PHP die übermittelten POST-Indizes mit dem gespeicherten Schlüssel. Das System lässt nur eine Erfolgsmeldung zu, wenn fehler_count === 0.
Personal-Sync: Nach erfolgreichem Quiz schreibt das System das Datum automatisch als Meta-Wert in den Datensatz des Mitarbeiters in der Personalverwaltung, wodurch das dortige Ampelsystem auf „Grün“ schaltet.
Risiko-Matrix: Jede Gefährdung wird in hs_gefaehrdungen_liste mit einer prioritaet (High, Mid, Low) gespeichert.
Visualisierung: Die Priorität steuert direkt die CSS-Klassen prio-high, prio-mid etc., was die visuelle Sortierung im QM-Dashboard ermöglicht.
Das Executive-Tool zur Überwachung aller Modul-Daten.
Daten-Aggregation:
Um SQL-Fehler bei deaktivierten Modulen zu vermeiden, nutzt das Modul die Hilfsfunktion $check_tab. Diese prüft über SHOW TABLES LIKE, ob die Modul-Tabelle existiert, bevor eine Abfrage gestartet wird.
Kennzahlen-Logik: Es werden gleichzeitig 6-8 COUNT-Abfragen ausgeführt (QM-Fristen, STK/MTK-Geräte, offene Urlaubsanträge, CIRS-Fälle). Das Ergebnis wird im Dashboard als "Kritische Kennzahlen" visualisiert.
Sichtbarkeits-Filter: Jede Kachel im Array besitzt den Schlüssel sichtbarkeit (alle oder chef).
Logik: Das Modul prüft via current_user_can('manage_options') oder über die in user_meta gespeicherte Job-Rolle, ob der User die Berechtigung für Chef-Kacheln hat. Falls nicht, wird die Kachel entweder gar nicht gerendert oder mit einem Schlosssymbol (🔒) versehen.
Dieses Modul dient der rechtssicheren Dokumentation von Personalgesprächen.
Daten-Isolation: Nutzt die Tabelle hs_mitarbeitergespraeche. Jedes Protokoll ist über praxis_id und mitarbeiter_name verknüpft.
Vertraulichkeits-Logik (Berechtigungstrennung):
Das Modul unterscheidet im PHP-Code strikt zwischen dem Feld ziele (für Mitarbeiter einsehbar) und notizen (🔒 Vertraulich).
Technische Sperre: Das Feld notizen wird nur gerendert, wenn current_user_can('manage_options') wahr ist. Selbst wenn ein Mitarbeiter das Protokoll im Frontend aufruft, wird der vertrauliche String gar nicht erst vom Server an den Browser gesendet.
Auto-Repair: Beim Modulstart prüft ein SQL-Hook, ob die Spalte praxis_id existiert. Falls nicht, wird sie per ALTER TABLE nachgerüstet, um die Abwärtskompatibilität zu alten Datensätzen zu sichern.
Ein Workflow-Management-System zur Einarbeitung neuer Fachkräfte.
Zustands-Überwachung (State Machine):
Tabelle: hs_onboarding_v22.
Funktionsweise: Jedes Onboarding-Thema besitzt vier Spalten für Zeitstempel (s1 bis s4).
Trigger: Beim Klicken auf eine Stufe sendet das System ein POST-Signal. Die Funktion hs_ob_action validiert den Nutzer und setzt via current_time('mysql') den exakten Zeitpunkt der Erledigung.
Progress-Algorithmus: * Das Modul berechnet die Einarbeitungsquote: ($ausgefuellte_stufen / $gesamt_stufen) * 100.
Dieser Wert wird im Chef-Dashboard zur Überwachung der Team-Integration visualisiert.
Schwellenwert-Berechnung:
Das Modul vergleicht das Feld naechste_faelligkeit mit current_date.
Technische Logik: PHP berechnet die Differenz in Tagen. Sinkt der Wert unter 30, wird das Bootstrap-Badge von green auf orange gewechselt. Ist der Wert negativ, schaltet das System auf bg-red-blink.
Personal-Sync: Das Modul führt beim Speichern einen Cross-Check mit hs_personal durch, um sicherzustellen, dass Vorsorgeuntersuchungen nur für aktive Mitarbeiter (Status 'aktiv') erfasst werden.
Dies ist der "Kleber" zwischen dem Kauf im Shop und der technischen Funktion in der Praxisumgebung.
Hook-Architektur: Nutzt woocommerce_order_status_completed.
Mapping-Logik:
Im Code ist ein assoziatives Array ($modul_mapping) hinterlegt, das WooCommerce Produkt-IDs den internen Modul-Namen (z.B. 'CIRS', 'Stempeluhr') zuordnet.
Ablauf: Sobald die Zahlung bestätigt ist, iteriert das System durch alle gekauften Items. Für jede Übereinstimmung im Mapping wird update_option('hs_mod_' . $modulname, '1') ausgeführt.
Echtzeit-Aktivierung: Da der Core-Loader (healthsuite-pro-alt.php) die Optionen bei jedem Seitenaufruf prüft, sind die Module ohne Neustart für den Kunden sofort verfügbar.
Metadata-Provisioning: * Das Modul klinkt sich in den woocommerce_thankyou-Hook ein.
Es rendert ein spezielles Formular, das nur einmalig nach dem Kauf erscheint.
Datenfluss: Eingegebene Daten (Subdomain-Wunsch, Praxis-Name) werden via update_post_meta direkt an die Bestellung angehängt. Der Administrator erhält so eine automatisierte E-Mail mit allen Informationen, um die neue Instanz final freizuschalten.
Ein Tool zur Sicherung der gesamten medizinischen Datenbankstruktur.
SQL-Meta-Extraction:
Das Modul nutzt $wpdb->get_col("SHOW TABLES LIKE '{$wpdb->prefix}hs_%'").
Dies stellt sicher, dass nur die spezifischen HealthSuite-Daten (und keine allgemeinen WordPress-Tabellen) gesichert werden.
Secure File Streaming:
Erstellte Backups werden in einem geschützten Verzeichnis (/wp-content/uploads/hs_backups/) gespeichert.
Download-Schutz: Der Download erfolgt nicht über einen direkten Link (um Directory-Listing zu verhindern), sondern über einen PHP-Buffer-Stream mit Nonce-Validierung. Nur wenn der hs_backup_nonce gültig ist, wird der Dateiinhalt via fpassthru() gesendet.
Die Schaltzentrale für die modulare Ladegeschwindigkeit.
Hot-Loading Logik:
Das Modul scannt das Verzeichnis /modules/.
Es führt für jede gefundene Datei einen Check gegen die wp_options durch: if (get_option('hs_mod_' . $name) === '1').
Nur aktive Module werden in den Arbeitsspeicher geladen. Dies ist die Grundlage für die Skalierbarkeit der Suite auf schwächeren Servern.
Validierungs-Engine:
Nutzt sanitize_textarea_field und sanitize_email zur Bereinigung.
Anti-Spam: Ein integrierter Nonce-Check (wp_verify_nonce) verhindert, dass automatisierte Bots massenhaft Support-Tickets an kontakt@saselicon-healthsuite.de senden.
Shortcode-Rendering: * Definiert Shortcodes wie [hs_marketing_page].
Technische Besonderheit: Die Seite lädt via ob_start() ein isoliertes CSS-Framework, das Konflikte mit dem Standard-Theme der Praxis verhindert. So bleibt das Corporate Design der HealthSuite auch auf verschiedenen Unterseiten (Kommunikation, Personal, Sicherheit) konsistent.
Ich verstehe vollkommen. Du suchst kein zusammenfassendes Handbuch, sondern eine vollständige technische Spezifikation, die jedes Modul auf Code-Ebene seziert. Da wir das Ziel von ca. 20 Seiten Tiefe verfolgen, werde ich nun in die maximale Detailtiefe gehen.
In diesem Block (Teil 5) dokumentieren wir die vollständige Datenbank-Architektur (SQL-Ebene) und den Core-Bootstrap-Prozess. Dies ist das technische Fundament, auf dem alle anderen 20+ Module aufbauen.
Jedes Modul der HealthSuite nutzt dedizierte Tabellen mit dem Präfix hs_. Hier ist die exakte technische Definition der Schemata, wie sie via dbDelta in den Snippets initialisiert werden.
hs_personal)Zweck: Master-Tabelle für alle Berechtigungen und Mitarbeiterdaten.
Felder:
id (INT, AI): Eindeutiger Primärschlüssel.
praxis_id (INT): Verknüpfung zum Inhaber/Mandanten (Sicherheits-Isolation).
vorname, nachname (VARCHAR 100): Stammdaten.
email (VARCHAR 150): Unique Identifier für Mail-Benachrichtigungen.
rolle (ENUM): 'MFA', 'Praxismanager', 'Inhaber'. Steuert die Sichtbarkeit im Dashboard.
pin (VARCHAR 10): 4-stellig, dient als kryptografischer Schlüssel für alle Terminal-Aktionen.
status (VARCHAR 20): Standard 'aktiv'. Archivierte Mitarbeiter werden durch SQL-Filter (WHERE status = 'aktiv') aus operativen Listen (Stempeluhr) entfernt.
Tabelle hs_stempeluhr:
mitarbeiter_id (INT): Fremdschlüssel zu hs_personal.
check_in / check_out (DATETIME): Zeitstempel.
typ (VARCHAR 50): 'Arbeit' oder 'Pause'.
Tabelle hs_urlaub_v81:
token (VARCHAR 64): Einzigartiger Hash für den 2-Stufen-Mail-Genehmigungsprozess.
tage_netto (INT): Berechneter Wert abzüglich Wochenenden/Feiertagen.
Tabelle hs_qm_dokumente:
version (INT): Inkrementeller Zähler. Jeder Upload triggert eine Erhöhung.
datei_url (TEXT): Pfad zur aktuellen PDF-Version.
Tabelle hs_qm_signs:
Verknüpft dokument_id, mitarbeiter_id und version.
Logik: Eine Abfrage (SELECT * FROM hs_qm_signs WHERE version = [aktuelle_version]) stellt sicher, dass bei einer neuen Version alle alten Unterschriften technisch "ungültig" werden (Force-Read-Mechanik).
heatlthsuite-pro-alt.php)Dieses Snippet fungiert als Kernel. Es steuert den Ladevorgang der restlichen 20+ Module.
Pfad-Konstanten: Definiert $hs_path via plugin_dir_path(__FILE__).
Erzwungenes Laden: Lädt zuerst healthsuite-core.php. Ohne diesen Kern bricht der Prozess ab.
Dynamic Inclusion Engine:
Scannt das Verzeichnis /modules/ mittels glob().
Iteriert durch alle .php Dateien.
Filter-Logik: Führt get_option('hs_mod_' . $name) aus. Nur wenn die Option in der Datenbank auf '1' gesetzt ist (durch Kauf oder Admin-Eingriff), wird die Datei geladen.
Vorteil: Dies verhindert "Fat-Plugins". Ein System mit 20 Modulen verbraucht nur den RAM für die 5 tatsächlich aktiven Module.
healthsuite-core.php)Der Kern stellt sicher, dass das System auch bei PHP-Inkompatibilitäten stabil bleibt.
Output Buffering: Startet ob_start(). Dies ist kritisch für die template_redirect Aktionen in Modulen wie dem Urlaubsmanager, um Headers already sent-Fehler bei Umleitungen zu vermeiden.
Selektive Fehlerunterdrückung: error_reporting(E_ALL & ~E_DEPRECATED & ~E_NOTICE & ~E_WARNING). In medizinischen Applikationen ist Verfügbarkeit wichtiger als syntaktische Perfektion. Das System unterdrückt "Rauschen" und fokussiert sich auf FATAL_ERRORS.
praxis_id)Jedes SQL-Statement in jedem Modul (z.B. im Geraetemanager.php oder Buchhaltungsmanagement.php) ist zwingend mit $wpdb->prepare und dem Filter WHERE praxis_id = %d ausgestattet.
Szenario: Wenn ein Inhaber (ID 5) eingeloggt ist, kann er technisch niemals die Geräte oder Personalakten von Inhaber (ID 6) sehen, da die praxis_id hart an die User-ID des Inhabers gekoppelt ist.
Dieses Modul agiert als Intrusion Detection System (IDS).
Überwachung: Es nutzt den Hook admin_init.
Reaktion: Erkennt es einen unbefugten Zugriff (z.B. durch den Demo-User besucher), wird die IP-Adresse und die versuchte Aktion in der Option hs_security_logs serialisiert.
Visualisierung: Diese Daten werden im Backend für den Administrator in einer Monospace-Log-Ansicht aufbereitet, um Brute-Force-Angriffe oder Rechte-Escalations frühzeitig zu erkennen.
Das System stellt zentrale Funktionen bereit, die von allen 20 Modulen genutzt werden:
hs_opt($key, $default): Sicherer Wrapper für get_option. Verhindert Typ-Fehler (Typ-Casting auf String).
hs_render_hero_buttons(): Erkennt die aktuelle URL und rendert kontextsensitiv entweder "Zurück zur Startseite" (auf Unterseiten) oder "Jetzt testen" (auf der Landingpage).
hs_auto_inject_dashboard(): Nutzt einen statischen Flag ($hs_injected), um sicherzustellen, dass das Dashboard niemals doppelt gerendert wird, selbst wenn mehrere Hooks gleichzeitig feuern.