Neue Website für eine Telemedizinklinik mit persönlichem Konto, Online-Registrierung und Stripe + Twilio-Integrationen (HIPAA-orientiert)

Ausgangslage: Eine kleine Telemedizin-Klinik verfügt derzeit nur über eine Landingpage auf Tilda ohne Registrierung oder Bezahlung. Die Registrierung erfolgt manuell per E-Mail; Nach der Zahlung erhält der Patient einen Link zu einem Videoanruf. Aufgrund manueller Vorgänge gehen Anwendungen verloren und es gibt keine normale Analyse.

Themenbereich und Ziel: Erstellen einer neuen Website mit einem öffentlichen Teil und einem persönlichen Patientenkonto, auf der Sie eine Dienstleistung und einen Arzt auswählen, sich für Freizeit anmelden, eine Beratung bezahlen und einen Link zu einer Videositzung erhalten können. Der Administrator muss die Terminplanung und Stornierungen verwalten. Es ist ein sorgfältiger Umgang mit personenbezogenen Daten, die Protokollierung von Aktionen und die Minimierung der Speicherung sensibler Informationen erforderlich.

Technische Umgebung und Einschränkungen:
- Bereitstellung auf dem vorhandenen AWS-Konto des Kunden (EC2 oder ECS, Sie können die beste Option vorschlagen), Domäne in Route53
- Stack: Next.js 14 (App Router) + TypeScript, PostgreSQL (RDS), Prisma, Docker, Terraform oder AWS CDK für Infrastruktur (teilweise akzeptabel, aber die Bereitstellung muss reproduzierbar sein)
- Authentifizierung: NextAuth oder gleichwertig mit E-Mail-Magic-Link, Brute-Force-Schutz, Ratenbegrenzung
- Zahlung: Stripe Checkout + Webhooks, korrekte Verarbeitung von Zahlungsstatus und wiederholten Ereignissen
- Benachrichtigungen: E-Mail (SES) und SMS (Twilio) über Registrierung/Übertragung/Stornierung
- Videokommunikation: Generierung einer sicheren Verbindung zur Sitzung über Twilio Video (ohne Speicherung von Aufzeichnungen)
- Daten: Speichern Sie keine medizinischen Dokumente und Diagnosen, sondern nur Besuchsmetadaten (Leistung, Zeit, Arzt, Status, Zahlung). Wir führen keine ärztlichen Atteste durch
- Sprachen: RU/EN (mindestens 6 Seiten des öffentlichen Teils + Konto)
- Design: kann auf einem vorgefertigten UI-Kit (z. B. shadcn/ui) ohne eindeutiges Rendering, aber mit einem einzigen Stil basieren

Spezifisches Ergebnis:
- Öffentliche Website: Startseite, Dienstleistungen, Ärzte, Preise, FAQ, Kontakte, Datenschutzbestimmungen
- Persönliches Konto des Patienten: Registrierung/Login, Profil, Liste der Besuche, Erstellen eines Eintrags, Stornieren/Übertragen im Rahmen der Regeln
- Admin-Panel (Sie können einen einfachen geschützten Bereich haben): Verwaltung von Ärzten, Diensten, Zeitplänen (Slots), Anzeige von Besuchen und Zahlungsstatus, manuelle Stornierung
- Integrationen: Stripe (Zahlung), SES (E-Mail), Twilio (SMS und Video), Webhooks, Ereignisprotokoll
- CI/CD: GitHub-Aktionen für Build und Bereitstellung, .env.example und Startanweisungen

Ausführungsschritte (erforderlich):
1) Kurze technische Analyse und Daten-/Flussdiagramm (Record-Payment-Call-Notifications) mit Fixierung der Annahmen
2) Implementierung von MVP-Registrierungs- und Zahlungsfunktionen mit Webhooks und einem Basiskonto
3) Benachrichtigungen hinzufügen und Videositzungen integrieren
4) Admin-Bereich, Tests, Stabilisierung, Bereitstellung und Dokumentation

Akzeptanzkriterien (messbar):
- Der Benutzer kann einen Eintrag für einen kostenlosen Slot erstellen und über Stripe bezahlen. Nach einem erfolgreichen Webhook ändert sich der Besuchsstatus in nicht mehr als 30 Sekunden auf „Bezahlt“.
- SMS und E-Mail werden beim Erstellen eines Datensatzes, erfolgreicher Zahlung, Stornierung und Übertragung gesendet (das Protokoll über erfolgreichen Versand und Fehler steht dem Administrator zur Verfügung)
- Der Link zu Twilio Video ist nur für Besuchsteilnehmer verfügbar und in der Zeitspanne aktiv: 10 Minuten vor dem Start bis 60 Minuten nach dem Start, danach nicht verfügbar
- Jeder Zugriff auf das Konto ohne Sitzung wird zum Login umgeleitet, alle API-Routen sind geschützt
- Mindestens 15 Autotests (Einheit/Integration) für kritische Szenarien: Besuch erstellen, Webhook verarbeiten, Zugriffsrechte
- Lighthouse für öffentliche Seiten: Leistung nicht unter 80 auf Mobilgeräten für die Haupt- und Serviceseiten (externe Stripe-Skripte zum Zeitpunkt der Zahlung ausgenommen)
- Anweisungen in README: lokaler Start in Docker, Anwenden von Migrationen, Festlegen von Umgebungsvariablen, Bereitstellung

Was ich meinerseits bereitstellen werde: Zugriff auf AWS, Stripe/Twilio/SES-Schlüssel, Seitentexte (Entwürfe) und eine Liste von Diensten/Ärzten in CSV. Es gibt keine Designdateien, eine sorgfältige Umsetzung auf vorgefertigten Komponenten ist erlaubt.

Wichtig: Das Projekt ist aufgrund der Kombination aus Zeitplänen, Zahlungen, Webhooks, Zugangsbeschränkungen und Infrastruktur komplex. Präferenz für eine Lösung, die ohne Magie und manuelle Bearbeitungen auf dem Server weiter unterstützt werden kann.