Einzelpraxis-Consult-Buchungs-Kit

Solo Consult Booking Kit – Buchung von Erstgesprächen für eine Einzelpraxis

⚠️ Bitte zuerst lesen – die HIPAA-Voraussetzung (bevor Sie irgendetwas bauen)

Dieses System ist nur dann HIPAA-konform, wenn es in einem Google Workspace-Konto mit einem unterzeichneten Business Associate Agreement (BAA) betrieben wird. Bauen Sie dieses System nicht, stellen Sie es nicht bereit und setzen Sie keine echten Klientendaten ein, bis alle folgenden Bedingungen erfüllt sind:

1. Sie haben Google Workspace (Business Starter, Standard, Plus oder eine gleichwertige abgedeckte Edition) auf Ihrer eigenen Praxis-Domain – nicht ein kostenloses persönliches Gmail-Konto (@gmail.com). Ein persönliches Konto hat kein verfügbares BAA zum Unterschreiben und darf dieses System oder seine Daten niemals enthalten.
2. Das Google Workspace BAA ist unterschrieben. Gehen Sie in der Google Admin-Konsole (Admin → Konto → Rechtliches / „Business Associate Amendment“ – der genaue Menüname ändert sich im Laufe der Zeit), überprüfen und akzeptieren Sie das BAA für Google Workspace / Cloud Identity und bewahren Sie eine Aufzeichnung des Datums auf. Die Unterzeichnung ist ein einmaliger Klick durch einen Workspace-Admin; wenn Sie es nicht finden können, halten Sie an und klären Sie das zuerst – fahren Sie nicht unter der Annahme fort, dass es abgedeckt ist.
3. Alles lebt in diesem Workspace-Konto. Die Apps Script-Projekte, die Buchungstabelle, der Kalender, der die Konsultationen empfängt, und das Postfach, das Bestätigungen sendet, müssen alle demselben Workspace-Benutzer (Ihnen) gehören. Führen Sie keinen Teil davon auf einem persönlichen Google-Konto aus und richten Sie Buchungen nicht auf einen persönlichen Kalender – ein persönliches Konto liegt außerhalb des BAA.
4. Kontohärtung ist aktiv: 2-Faktor-Authentifizierung für das Konto erzwungen (Passkeys / Advanced Protection sind besser), ein starkes, eindeutiges Passwort in einem Passwort-Manager und von Ihnen kontrollierte Wiederherstellungsoptionen.

Software kann nicht „HIPAA-zertifiziert“ sein, und dieses Kit macht eine Praxis nicht von allein HIPAA-konform. Es ist mit HIPAA-unterstützenden Sicherheitsvorkehrungen gebaut (Datenminimierung, gehashte, zeitlich begrenzte Verwaltungslinks, generische Kalenderereignisse, Aufbewahrungsbereinigung, Prüfprotokoll – siehe references/security-and-hipaa.md), und es läuft auf einem Anbieter (Google), der ein BAA unterzeichnet. Die Einhaltung erfordert auch Ihre eigene Risikoanalyse, Richtlinien, Schulungen und eine Mitteilung über Datenschutzpraktiken. Wenn eine der oben genannten Voraussetzungen fehlt, besteht die erste Aufgabe des Agenten darin, dem Inhaber zu helfen, dies zu beheben – nicht, die Apps zu bauen.

Zweck

Geben Sie einem Einzelpraktiker das Buchungssystem, das eine Gruppenpraxis verwendet, ohne die Gruppenmechanik:

• Teil A – Öffentliche Buchungs-App. Eine öffentliche Webseite (eingebettet in die Praxis-Website), auf der ein potenzieller Klient einen kurzen Eignungscheck beantwortet (Bundesland, Zahlung, für wen die Konsultation ist, Sprache), nur wirklich offene Zeitslots sieht – Ihre deklarierten Sprechzeiten abzüglich der belegten Zeiten Ihres echten Kalenders, Ihrer Auszeiten und bestehender Buchungen – und ein kostenloses Erstgespräch bucht (standardmäßig 15 Minuten; konfigurierbar). Der Klient erhält eine Bestätigungs-E-Mail mit einer .ics-Datei und einem privaten Link zum Umbuchen/Stornieren; Sie erhalten eine minimale Benachrichtigung. Erinnerungen (~24h vorher) und Nachgesprächs-Folge-E-Mails laufen auf einem Timer.
• Teil B – Eigentümer-Konsole (eine App, drei Ansichten). Eine private, PIN-geschützte App, die nur Sie verwenden, und die das zusammenführt, was eine Gruppenpraxis auf drei Apps aufteilt:
  • Meine Konsultationen – bevorstehende / vergangene / stornierte Konsultationen, vollständige Details per Klick, eine vergangene Konsultation als Nichterscheinen markieren.
  • Verfügbarkeit – wöchentliche Sprechzeiten festlegen (geteilte Tage möglich), tagesgenaue Zeiten, Auszeiten, Annahme neuer Klienten ein/aus, und Buchungseinstellungen (eine Begrenzung der Konsultationshäufigkeit, Mindestvorlauf, Puffer, Slot-Intervall); sehen Sie Ihre bereinigte Verfügbarkeit und die nächsten 7 Tage offener Slots genau so, wie die Buchungsseite sie berechnet.
  • Einstellungen & Werkzeuge – Bearbeiten Sie jede E-Mail-Vorlage und Buchungsregel ohne Code, sehen Sie Buchungsstatistiken und das Prüfprotokoll, exportieren Sie Prüf-/Buchungs-CSV (niemals die Verwaltungs-Tokens).

Referenzimplementierung: zwei Google Apps Script-Web-Apps, unterstützt durch eine Tabelle und Ihren eigenen Google Kalender. Kein Drittanbieter-Buchungsservice, keine Analysen, keine Tracker.

Was die Solo-Edition bewusst weglässt (Gruppe → Solo)

• Keine „Verbinden Sie Ihren Kalender“-App. In einer Gruppenpraxis existiert diese App aus einem Grund: Jeder Anbieter, angemeldet als er selbst, teilt seinen Kalender mit dem zentralen Konto der Praxis mit der Berechtigung „Änderungen an Ereignissen vornehmen“ und registriert die Kalender-ID zurück im Buchungssystem. Ein Solo-Eigentümer ist der Skript-Eigentümer und der Kalender-Eigentümer – die Buchungs-App läuft bereits als Sie, mit Eigentümerzugriff auf Ihren Kalender. Es gibt nichts zu teilen und nichts zu registrieren. Die Einrichtung ist einfach: Setzen Sie die ID Ihres Kalenders in das Config-Tab (die ID Ihres primären Kalenders ist einfach Ihre E-Mail-Adresse; oder erstellen Sie einen dedizierten „Erstgespräche“-Kalender im selben Workspace-Konto und verwenden Sie dessen ID), führen Sie dann das integrierte checkSetup() aus und bestätigen Sie, dass es accessRole=owner und freebusy=OK meldet.
• Keine Anbieterliste-Arbeitsmappe und kein Abgleich von Anbietern. Ein Kliniker = eine Config-Zeile mit Name, Qualifikationen, lizenzierten Bundesstaaten, Panels, Sprachen, Altersgruppen, Gleit-Skala-Flag, Bio-Link, Zeitzone, Kalender-ID. Kein Abgleich-Job, keine Anbieter-IDs, die an andere weitergegeben werden.
• Keine Anbieterzuweisungs-/Routing-Engine. Der Gruppen-Assistent leitet einen Klienten zum richtigen Kliniker weiter. Der Solo-Assistent prüft nur die Passung zu Ihnen: falscher Bundesstaat, ein von Ihnen nicht akzeptiertes Panel, eine von Ihnen nicht bediente Altersgruppe oder keine Gleit-Skala, wenn diese erforderlich ist → eine klare Nicht-Passungs-Nachricht mit Ihrer Kontakt-E-Mail, niemals eine Sackgasse.
• Nichts mit mehreren Anbietern: keine PINs pro Anbieter in einer gemeinsamen Liste (eine Eigentümer-PIN, gehasht, im Config-Tab), kein „Bearbeiten im Auftrag von“, kein Anbieterfilter, keine praxisweite Auszeit (Ihre Auszeit ist einfach Ihre Auszeit).

Übergabe an Ihren Agenten (für den Kollegen, der dieses Kit erhält)

Dieses Kit ist plattformneutral: Es ist reines Markdown (das offene Agent Skills-Format) und funktioniert mit jedem fähigen KI-Agenten – einem Skill-ladenden Agenten, einem Coding-Agenten mit einem Workspace oder einem Nur-Chat-Agenten mit hochgeladenen Dateien. README.md in diesem Ordner enthält die plattformspezifischen Anweisungen und PROMPT.md einen kopierbaren Start-Prompt; beide Wege führen zur gleichen Stelle:

1. Bestätigen Sie, dass die HIPAA-Voraussetzung oben erfüllt ist (Workspace + unterzeichnetes BAA + Härtung). Wenn nicht, tun Sie das zuerst.
2. Beantworten Sie das Einrichtungsinterview unten – der Agent sollte einmal fragen, vor dem Bauen.
3. Lassen Sie den Agenten beide Apps bauen und testen, führen Sie die Test-Checkliste in references/test-checklist.md mit Testbuchungen durch, und tauschen Sie erst dann Ihre öffentlichen Links gegen die neue Buchungsseite aus.

Behalten Sie Ihren alten Buchungslink (falls vorhanden) als Fallback bei, bis die Test-Checkliste Ende-zu-Ende bestanden ist.

Anweisungen für den Agenten, der dies baut (jede Plattform)

• Arbeiten Sie von diesen Dateien aus, nicht aus dem Gedächtnis ähnlicher Systeme. Lesen Sie diese Datei und jede Referenz, bevor Sie Code schreiben. Wenn eine Referenz und die Live-Anweisung des Eigentümers in Konflikt geraten, gewinnt die Anweisung des Eigentümers und die Änderung wird notiert.
• Ihre Ausgabe sind Dateien + überprüfte Schritte, unabhängig von Ihren Werkzeugen. Erstellen Sie jedes Projekt als einfügebereite Dateien (Code.gs, Index.html, Manage.html wo zutreffend, appsscript.json). Wenn Sie direkten Zugriff auf das Google-Konto des Eigentümers oder einen Apps Script API/Deploy-Pfad haben, können Sie bereitstellen – aber nur mit Zustimmung des Eigentümers, und Sie überprüfen trotzdem vom ausgelieferten Ergebnis. Wenn Sie diesen Zugriff nicht haben (die meisten Chat-Agenten haben ihn nicht), übergeben Sie die Dateien und führen Sie den Eigentümer Schritt für Schritt durch references/setup-and-deploy.md: Die Google-Anmeldung, die Autorisierung von Bereichen und die Bereitstellungsaktionen sind vom Eigentümer durchzuführen, und ein Agent, der dies nicht kann, sollte dies klar sagen, anstatt zu implizieren, er habe etwas bereitgestellt.
• Testen Sie in den Formen, die die Produktion verwendet. Bauen Sie eine lokale Testumgebung, die die Tabellen-/Kalkulationsschicht stubbt und jede Serverfunktion in den exakten Argumentformen aufruft, die der ausgelieferte Client sendet. Führen Sie sie nach jeder Codeänderung aus, nicht nur am Ende.
• Erfordern Sie niemals eine anbieterspezifische Funktion. Alles hier ist Google Apps Script + Sheets + Calendar + Gmail plus Markdown. Wenn Ihre Plattform eine Annehmlichkeit bietet (eine Deploy-Integration, ein Datei-Tool), nutzen Sie sie, aber der Bau darf nicht davon abhängen – dasselbe Kit muss für den nächsten Eigentümer auf einem anderen Agenten funktionieren.

Einrichtungsinterview (einmal sammeln, aufschreiben, niemals raten)

• Voraussetzung: Workspace-Domain, das Konto, dem alles gehören wird (z.B. [email protected]), BAA unterschrieben (Datum), 2-Faktor-Authentifizierung aktiv.
• Praxis: Praxisname, Ihr Name + Qualifikationen, wie Klienten sie sehen sollen, Praxis-Kontakt-E-Mail, Benachrichtigungs-E-Mail (kann dieselbe sein), Website-URL, Datenschutzrichtlinien-URL.
• Kalender: Primärer Kalender oder ein dedizierter Konsultationskalender im selben Konto? Seine ID kommt in Config. (Empfohlen: dedizierter Kalender – Konsultationstermine bleiben visuell getrennt, und Sie können die Frei/Gebucht-Informationen dieses Kalenders freigeben, ohne die Inhalte Ihres Hauptkalenders offenzulegen. In beiden Fällen liest die App nur Frei/Gebucht und schreibt generische Konsultationstermine.)
• Passungsprofil (treibt die Zahlungs-/Berechtigungsoptionen des Assistenten – aus Config generiert, niemals in der Seite hartcodiert): Bundesstaaten, in denen Sie lizenziert sind; Versicherungspanels, EAPs und Fonds, die Sie akzeptieren (exakte, klientenorientierte Namen); Selbstzahler und Gleit-Skala (ja/nein, und eventuelle Formulierung der Untergrenze, die Sie öffentlich verwenden); Sprachen, in denen Sie Therapie anbieten; wen Sie behandeln (Erwachsene / Jugendliche / Kinder / Paare / Familien); ob Sie Klienten außerhalb der USA sehen (wenn ja: Konsultationen sind immer noch kostenlos, aber die laufende Therapie ist nur privat bezahlt/Gleit-Skala – der Assistent schränkt die Zahlungsoptionen entsprechend ein).
• Buchungsregeln (Standardwerte aus dem Referenzsystem – bestätigen oder ändern): Konsultationslänge 15 Min.; Buchungsfenster 14 Tage; Mindestvorlauf 12 Stunden; Slot-Raster alle 30 Minuten; Puffer 10 Minuten um belegte Ereignisse; Umbuchungs-/Stornierungsfrist 4 Stunden; Erinnerung 24h vorher; Nachgesprächs-Folge 5 Minuten nach Ende der Konsultation; eine aktive Konsultation pro Klienten-E-Mail/Telefon (Dublettenschutz aktiv).
• Verfügbarkeit zum Starten: Ihre anfänglichen wöchentlichen Sprechzeiten + Zeitzone, damit die Seite vom ersten Tag an echte Slots hat. (Sie werden diese danach in der Konsole pflegen.)
• E-Mail-Formulierungen: Bestätigungs-, Erinnerungs- und Folge-E-Mail-Vorlagen (Platzhalter wie {ClientVorname}, {EventDatumZeit}, {AnbieterName}); der Umfrage-/Nächste-Schritte-Link, auf den die Folge-E-Mail verweist; der Absendername/die Absenderadresse (Ihre Adresse oder ein Send-As-Alias auf Ihrem Konto wie [email protected] – Aliase benötigen einen zusätzlichen OAuth-Bereich, siehe die Deploy-Referenz).
• Branding: Das Erscheinungsbild Ihrer Website für die öffentliche Seite (Schriftarten, Textfarbe, Akzentfarbe für Schaltflächen/Links, Eckenstil). Die öffentliche Seite verwendet einen flachen Website-Stil – keine Portal-Glas/Aurora-Effekte, kein Google-Branding, keine nativen Browser-Dialoge.
• Sprache(n): Nur Englisch oder zweisprachig? Das Referenzsystem unterstützt eine zweite vollständige Sprache (einen übersetzten Fragensatz, E-Mails in der Sprache, die der Klient bei der Buchung gewählt hat). Fügen Sie sie nur hinzu, wenn Sie tatsächlich Klienten in dieser Sprache bedienen.
• Datenschutzhinweis: Der kurze Buchungsformular-Datenschutztext, den Klienten bestätigen müssen (was gesammelt wird, dass die E-Mail nicht auf Notfälle überwacht wird, Krisenhotline 988 / 911 in den USA). Jede Buchung speichert den Zeitstempel der Bestätigung + die Hinweisversion. Erhöhen Sie die Versionszeichenfolge, wann immer sich der Text ändert.

Wie alles zusammenhängt (ein Absatz)

Beide Apps laufen als Sie (USER_DEPLOYING) innerhalb Ihres Workspace-Kontos. Die Buchungs-App ist öffentlich und anonym: Besucher sehen niemals die Tabelle oder Kalenderdetails – die Verfügbarkeit wird nur aus Frei/Gebucht berechnet. Eine Buchung, die unter einer Skriptsperre getätigt wird, sodass zwei Besucher nicht denselben Slot nehmen können, schreibt eine Zeile in das Termine-Tab, erstellt ein Ereignis mit generischem Titel („Erstgespräch – “, minimale Beschreibung, kein Kliententeilnehmer) in Ihrem Kalender und sendet eine E-Mail an den Klienten (Bestätigung + .ics + privater Verwaltungslink, Token nur als SHA-256-Hash gespeichert) und an Sie (Triage-Minimum, kein Klientenname im Betreff). Ein 5-Minuten-Timer sendet Erinnerungen und Folge-E-Mails und führt die Aufbewahrungsbereinigung durch. Die Konsole ist PIN-geschützt, liest/schreibt dieselbe Arbeitsmappe und ist der einzige Ort, an dem vollständige Buchungsdetails eingesehen werden. Vollständiges Datenmodell und Vorrangregeln: references/architecture.md.

Bau-Reihenfolge (nicht umordnen)

1. Arbeitsmappe + Buchungs-App gemäß references/booking-app-spec.md und references/setup-and-deploy.md (Tabelle erstellen, setupSheet(), checkSetup(), setupTriggers() ausführen, bereitstellen).
2. Konsolen-App gemäß references/console-app-spec.md (PIN-Sperre, Meine Konsultationen, Verfügbarkeit, Einstellungen & Werkzeuge) gegen dieselbe Arbeitsmappe.
3. Testen mit references/test-checklist.md – echte Ende-zu-Ende-Testbuchung, Doppelbuchungsversuch, Umbuchung/Stornierung über den gemailten Link, Nicht-Passungs-Pfad, Erinnerung/Folge per Hand.
4. Live gehen: Betten Sie die Buchungs-App auf der Buchungsseite Ihrer Website ein, tauschen Sie die öffentlichen Links aus, behalten Sie den alten Link als Fallback, bis Sie sauber eine echte Buchung entgegengenommen haben.

Harte Regeln für den Agenten (das sind die teuren Lektionen)

• Bereiche: Deklarieren Sie den vollständigen https://www.googleapis.com/auth/spreadsheets-Bereich, wann immer Code SpreadsheetApp.openById aufruft – der Nur-Lese-Bereich lässt jeden solchen Aufruf fehlschlagen. Wenn die App E-Mails mit sowohl GmailApp als auch MailApp sendet, deklarieren Sie beide gmail.send und script.send_mail (gmail.send allein deckt MailApp nicht ab, und die Fehler werden von try/catch geschluckt – E-Mails werden stillschweigend nie gesendet). Das Senden von einem Send-As-Alias über GmailApp benötigt auch gmail.settings.basic. Die Kalenderfunktionen benötigen den erweiterten Kalenderdienst (v3), der im Manifest aktiviert ist.
• Bereitstellungen: Erhöhen Sie nach der ersten Bereitstellung immer die bestehende Bereitstellung auf eine neue Version. Erstellen Sie niemals eine neue Bereitstellung – eine neue URL zerstört jede Einbettung und jeden Link, und die alte URL serviert weiterhin alten Code. Lesen Sie bereitgestellte Inhalte zurück / überprüfen Sie servierte Markierung …

[... zur Übersetzung gekürzt]