Patientensicht
- Die meisten Informationen liegen nur auf Papier vor
- Therapiepläne ändern sich kurzfristig
- Die Orientierung fällt schwer: Welcher Raum, welche Etage?
- Unsicherheit: Was brauche ich, was ziehe ich an?
- Kaum Überblick über die ganze Woche
← Alle Projekte
Projekt 03 · Produktprototyp · Digitalisierungskonzept für das Gesundheitswesen · 2026
Reha
Ein Reha-Planer aus Patientensicht.
Rehabilitation besteht aus wochenlangen Therapien, Terminen, Räumen, Dokumenten, Mahlzeiten und kleinen täglichen Entscheidungen, die größtenteils auf Papier festgehalten werden. Nachdem ich diesen Arbeitsablauf aus erster Hand erlebt hatte, modellierte ich ihn, entwarf einen verbundenen Wochenplan für Patienten und Klinikteams und baute einen funktionierenden Prototyp, RehaConnect, den ich später Rehabilitationsorganisationen vorschlug.
Prototyp, kein Produkt im Einsatz. Mit Testdaten erstellt, vor Ort demonstriert, als Konzept präsentiert. Es wurde nie im klinischen Live-Betrieb eingesetzt und nie von echten Patienten oder Personal verwendet.
01 · Das Erlebnis
Ein Reha-Aufenthalt besteht aus vielen Momenten, die zusammenpassen müssen.
Drei Wochen lang durchläuft ein Patient ein dichtes Programm: Therapien, ärztliche Beratungen, Gruppentraining, Mahlzeiten, Freizeitangebote, Dokumente und Ziele, verteilt auf Räume und Etagen, mit einem kurzfristig wechselnden Plan. Von innen betrachtet ist der Aufenthalt kein medizinischer Prozess. Es ist ein Zeitplan, den Sie einhalten müssen.
- Therapien
- Termine
- Dokumente
- Beurteilungen
- Ziele
- Mahlzeiten
- Freizeitangebote
- Räume und Etagen
- Kommunikation
- Fortschritt
02 · Das Problem
Die gleichen Informationen werden von allen benötigt und liegen auf dem Papier vor.
Therapeuten und Mitarbeiter
- Hoher organisatorischer Aufwand
- Pläne müssen häufig angepasst werden
- Schwere Koordination bei Vollbelegung
- Anwesenheitslisten und Dokumentation auf Papier
- Wenig Zeit für individuelle Patientenfragen
GeduldigPapier · Telefon · Schwarzes Brett
TherapeutenPapier · Telefon · Schwarzes Brett
ÄrztePapier · Telefon · Schwarzes Brett
VerwaltungPapier · Telefon · Schwarzes Brett
Dokumentation
Wenn sich der Plan ändert, erfolgt jede Übergabe manuell: Der Therapeut plant neu, der Patient fragt, die Rezeption antwortet, die Liste wird neu gedruckt.
Beobachtungen, die während des Aufenthalts von beiden Seiten, Patienten und Personal, aufgenommen und als Ausgangspunkt des Konzepts genutzt werden.
03 · Die Produktidee
Ein verbundener Wochenplan, gesehen von jeder Rolle.
Das Konzept bildet jede beobachtete Reibung auf eine digitale Antwort ab und hält den Patiententag im Mittelpunkt des Systems.
| Beobachtung im Alltag | Idee für eine digitale Lösung |
|---|---|
| Therapiepläne ändern sich häufig | Ein digitaler, immer aktueller Wochenplan |
| Patienten fragen immer wieder, wo ein Zimmer sei | Raum und Etage werden bei jeder Sitzung angezeigt, mit einer Navigationskarte |
| Unsicherheit über Kleidung und Material | Was Sie pro Sitzung anziehen und was Sie mitbringen sollten |
| Freizeit ist schwer zu planen | Übersicht über freie Slots und optionale Angebote |
| Viel Papier | Digitale Informationen statt Ausdrucke |
- 01RehaBildungsaufenthalt
- 02Wochenplan
- 03Sitzung: Einräumen, anziehen, mitbringen
- 04Orientierung
- 05Check-in und Anwesenheit
- 06Ansicht des Therapeutentages
- 07Klinikübersicht
PatientenMehr Orientierung, eine planbare Woche, weniger offene Fragen.
TherapeutenWeniger zu beantwortende Fragen, weniger organisatorischer Aufwand.
VerwaltungWeniger Papier, ein klarerer Überblick über das Haus.
04 · Wie es funktioniert
Drei Rollen, ein Tag.
Geduldig
Mein Tag und meine Woche: Sitzungen mit Zimmer, was ich anziehen und mitbringen soll, morgendlicher Check-in, Mahlzeiten, Freizeitangebote, Ziele, Dokumente, Neuigkeiten und eine Navigationskarte.
Am vollständigsten; Mehrere Teile sind UI über statischen Daten.Therapeut
Die heutigen Sitzungen mit Teilnehmern, QR-Scanning zur Anwesenheitskontrolle, Aktualisierungen aus der Klinik, Kabinenbelegung und eine Einrichtungskarte.
Fahrplan und Kabinen sind statische Daten; Die Anwesenheit bleibt im Browser.Verwaltung
Patientenliste und Erstellung über die API, Patientendetails mit ausdruckbarem QR-Login sowie ein Dashboard für Stationen, Therapiepläne, Mahlzeiten, Räume und Analysen.
Patienten-CRUD ist real; Das Dashboard besteht aus Scheindaten.Echtes BackendBrowserstatusStatische Daten
- Der Patient meldet sich anper Code oder QR; Die ID wird anhand der API überprüft
- Check-in am Morgen„Wie fühlst du dich heute?“ wird an den Check-in-Endpunkt gesendet
- Wochenplan und TagesansichtSitzungen mit Raum, Tragen, Mitbringen und Nutzen aus den Zeitplandaten
- Orientierung„Zum Raum navigieren“ öffnet den Grundriss
- Mahlzeiten, Ziele, freie Plätzeausgewählt und im Browser gesperrt
- Der Therapeut scannt den Sitzungs-QRDie Anwesenheit wird im Browser erfasst; Der API-Endpunkt ist vorhanden, aber nicht verkabelt
- Verwaltung schafft Patientenüber die API, mit einem ausdruckbaren QR-Login
05 · Patientenerfahrung
Mein Tag, meine Woche und was ich für die nächste Sitzung brauche.
Die Kernidee
Was man anzieht, was man mitbringt, wohin man geht.
Zu jeder Sitzung gehört ein Raum, eine Benefizlinie, eine Bekleidungsliste und eine Ausrüstungsliste. Im Backend handelt es sich hierbei um validierte Felder im Zeitplandatensatz, nicht um Freitext. Es beantwortet die Frage, die ein Patient tatsächlich um 08:45 Uhr hat: Was brauche ich für die Sitzung um 09:00 Uhr und wie komme ich dorthin?
Außerdem im Patientenbereich: Wöchentliche Menüauswahl mit Sperrfrist, Gewichtsziel mit BMI-Bereich, Freizeitbuchung, Kursunterlagen nach Diagnose, Kliniknews und ein Lageplan. Diese laufen auf statischen Daten und dem Browserstatus.
06 · Klinikerfahrung
Am selben Tag von Seiten des Therapeuten und der Klinik.
Orientierung für beide Seiten
Räume, Kabinen und Etagen als gemeinsame Karte.
Patienten erhalten über die Sitzungsdetails eine Route zu ihrem Zimmer. Therapeuten sehen, welche Kabine gerade frei, reserviert oder belegt ist. Beide Ansichten zeigen das gleiche Raum- und Kabinenmodell.
07 · Daten- und Systemmodell
Den Reha-Aufenthalt modellieren.
Vier Entitäten werden vom Backend beibehalten; Der Rest der Domain wird im Frontend eingegeben und von statischen Geräten gespeist. Die Aufteilung ist genau dort, wo der Prototyp endet und das Produkt beginnen würde.
Wird von der API beibehalten
Typisierte, statische Vorrichtungen
Beziehungen: Zeitplan, Anwesenheit und Check-in beziehen sich auf einen Patienten; Die Anwesenheit verweist auf einen Zeitplan. Rund neunzig TypeScript-Schnittstellen beschreiben die Frontend-Domäne, kompiliert im strikten Modus.
08 · Ingenieurwesen
Wie der Prototyp funktioniert.
Browser · React 18 SPA
Patientenansichten
Ansichten des Therapeuten
Admin-Ansichten
sessionStorage-Rolle · localStorage-Auswahlmöglichkeiten
Express-API
Patienten · Zeitpläne · Anwesenheit · Einchecken
Validierung · Konfliktprüfung · idempotentes Einchecken
JSON-Dateien, atomare Schreibvorgänge
Statische Vorrichtungen
Wochenplan · Therapeutenplan · Menüs
kostenlose Sitzungen · Kabinen · Räume · Neuigkeiten · Dokumente
Clinic.json White-Label-Konfiguration
- Frontend
- React 18, TypeScript (streng), Vite 5, Tailwind CSS 4, React Router, i18next mit Deutsch, Englisch und Französisch bei voller Schlüsselparität, qrcode.react und html5-qrcode
- Backend
- Node.js mit Express 4 und CORS; 11 Routen; handschriftliche Validierung; ein JSON-Dateispeicher mit atomaren temporären Dateischreibvorgängen
- Rollen
- Patient, Therapeut, Verwaltung: drei Einstiegspunkte, jeder mit seiner eigenen Sicht auf den gleichen Tag
- Staat
- Sitzung pro Rolle in sessionStorage; Mahlzeiten, Ziele, Buchungen und Therapeutenbesuche in localStorage; Drei Schreibpfade erreichen den Server
- Tests, CI, Bereitstellung
- Keine. Das Projekt verfügt über keine Testsuite, keine Pipeline und keine Bereitstellungskonfiguration
API-Oberfläche
GET /api/patientsGET /api/patients/:idPOST /api/patientsGET /api/schedulesGET /api/schedules/:idPOST /api/schedules (conflict check)GET /api/attendancePOST /api/attendance (upsert)GET /api/checkinPOST /api/checkin (once per day and type)GET /api/health
Prototyp versus Serienreife
| Bereich | Im Prototyp | Vor dem klinischen Einsatz erforderlich |
|---|---|---|
| Authentifizierung | Codesuche anhand einer bereitgestellten JSON-Datei; Die Patienten-ID ist der Ausweis | Echte Identität, Sitzungen, Rollen und Einwilligung |
| Beharrlichkeit | JSON-Dateien auf der Festplatte, keine Sperrung; Die meisten Zustände werden im Browser angezeigt | Eine Datenbank mit Migrationen, Backups und Mandanten |
| Datenschutz | Keine Verschlüsselung, kein Audit-Log, keine Aufbewahrungsregeln | DSGVO-Prozesse, Audit Trail, Löschung und Zugriffsrechte |
| Integration | Vorrichtungsdaten; keine Kliniksysteme angeschlossen | Schnittstellen zu Planungs-, KIS- und Dokumentationssystemen |
| Regulatorisch | Nicht bewertet | Überprüfung der Klassifizierung von Medizinprodukten, Sicherheitsüberprüfung, Zugänglichkeit |
| Klinische Validierung | Keine; niemals von Patienten oder Personal verwendet | Pilotprojekt mit klinischen Interessenvertretern, gemessene Ergebnisse |
09 · Vom Erlebnis zum Prototyp
Von der Beobachtung zum Prototyp.
- Erfahren
Tägliche Teilnahme an einem Rehabilitationsprogramm; Gespräche mit anderen Patienten, Therapeuten und Mitarbeitern; die Routinen beobachten.
- Beobachtet
Papierpläne, kurzfristige Änderungen, Orientierungsprobleme, Kleidungsunsicherheit, kein Wochenüberblick; hoher Koordinationsaufwand für das Personal.
- Modelliert
Der Aufenthalt als Patienten, Sitzungen, Anwesenheit, Check-ins, Mahlzeiten, Kabinen und Zimmer, mit Tragen und Mitbringen bei jeder Sitzung.
- Entworfen
Ein patientenorientierter Wochenplan mit Tagesansicht und Rollenansichten für Therapeuten und Verwaltung derselben Daten.
- Gebaut
RehaConnect im Januar 2026, abends und am Wochenende, nur mit Testdaten, als funktionierender lokaler Prototyp.
- Vorgeschlagen
Präsentation als Digitalisierungskonzept bei Reha-Organisationen, gerahmt für die DRV-Modellprojektroute mit der Klinik als Antragsteller.
10 · Was als nächstes geschah
Stand des Prototyps und nächste Schritte.
Das Konzept wurde Rehabilitationsorganisationen vorgeschlagen. Es kam nicht in die Produktion und der Prototyp wurde nie im klinischen Betrieb eingesetzt.
Das ist die normale Form der Digitalisierung im Gesundheitswesen. Die Erstellung der Software ist ein Teil. Für die Einführung sind außerdem institutionelle Kapazitäten, ein Finanzierungs- und Beschaffungsweg, die Integration in bestehende Kliniksysteme, eine Überprüfung von Vorschriften und Sicherheit, organisatorische Änderungen und eine Abstimmung mit klinischen Interessengruppen erforderlich. Keines dieser Probleme wird durch einen Prototyp gelöst, so vollständig er auch aussieht.
11 · Was ich gelernt habe
- Modellieren Sie die Domäne vor der BenutzeroberflächeDie nützlichste Idee im Prototyp ist ein Datenfeld: Tragen Sie es bei jeder Sitzung und bringen Sie es mit. Sobald die Domäne es enthielt, konnte es auf jedem Bildschirm angezeigt werden.
- Design vom Patiententag anDer Plan, der zählt, ist Mittwoch um 09:00 Uhr in der Physiotherapie 1 mit Sportkleidung und einem Handtuch, nicht ein Krankenhausinformationssystem.
- Zwei Perspektiven auf einen ZeitplanPatienten und Therapeuten betrachten dieselbe Sitzung von unterschiedlichen Seiten: wohin gehe ich und wer ist hier? Der Prototyp gibt jeder Seite ihre eigene Sicht auf die gemeinsam genutzten Daten.
- Der Workflow-Status ist das ProduktCheck-ins, Anwesenheit, gesperrte Essensauswahl und gebuchte Slots sind Zustände, keine Bildschirme. Der Prototyp modelliert sie, behält die meisten davon jedoch im Browser; Die eigentliche Arbeit besteht darin, sie hinter eine API zu verschieben.
- Privatsphäre prägt die ArchitekturBei einem Reha-Plan handelt es sich um Gesundheitsdaten. Alles, was über einen Prototyp hinausgeht, beginnt mit Identität, Einwilligung, Prüfung und Aufbewahrung, nicht mit Funktionen.
- Adoption ist ein eigenes SystemEine Klinik übernimmt diese durch Finanzierungswege, Beschaffung, IT-Überprüfung und Personalzeit. Softwarebereitschaft ist notwendig, nicht ausreichend.
Wahrheitstabelle
Gebaut, vorgeschlagen, demonstriert, Produktion.
- Gebaut
- Drei Rollenansichten, ein Patientenwochenplan mit Tragen/Mitbringen pro Sitzung, QR-Login und Anwesenheit, morgendlicher Check-in, Mahlzeiten, Freizeitangebote, Ziele, Nachrichten, Dokumente, Navigationskarte, Kabinenbelegung, Admin-Dashboard, eine Express-API mit einem JSON-Shop, drei Sprachen.
- Vorgeschlagen
- Digitale Unterstützung für den Reha-Alltag, gefördert durch ein DRV-Modellprojekt mit der Klinik als Antragsteller und meinem Unternehmen als technischem Partner. Serverseitige Anwesenheit, echte Konten, Klinikintegration und Hosting waren nur Konzepte.
- Demonstriert
- Alles auf dieser Seite läuft lokal auf synthetischen Daten: End-to-End-Reisen von Patienten, Therapeuten und Administratoren, Patientenerstellung über die API, QR-Generierung, Anwesenheits- und Check-in-Endpunkte.
- Produktion
- Nie im klinischen Live-Betrieb eingesetzt. Niemals von echten Patienten oder Personal verwendet. Nicht klinisch validiert, nicht zertifiziert, nicht auf Medizinprodukte- oder Datenschutzkonformität geprüft.
Alle Screenshots auf dieser Seite stammen vom Prototyp, der lokal auf einem vollsynthetischen Datensatz läuft (fiktive Patientin „Anna Meier“, fiktive Klinik „Reha-Zentrum Waldsee“). Es wird keine Klinik, kein Patient oder kein Mitarbeiter identifiziert.