Projet 03 · Prototype de produit · Concept de numérisation des soins de santé · 2026
Un outil de planification de rééducation conçu du point de vue d’une patiente.
Rehabilitation, ce sont des semaines de thérapies, de rendez-vous, de chambres, de documents, de repas et de petites décisions quotidiennes, rassemblées principalement sur papier. Après avoir expérimenté ce flux de travail, je l'ai modélisé, conçu un plan hebdomadaire connecté pour les patients et les équipes cliniques, et construit un prototype fonctionnel, RehaConnect, que j'ai ensuite proposé aux organismes de réadaptation.
Prototype, pas un produit en cours d'utilisation. Construit avec des données de tests, démontrées localement, présentées comme un concept. Il n’a jamais été déployé en opération clinique réelle et n’a jamais été utilisé par de vrais patients ou membres du personnel.
01 · L'expérience
Pendant trois semaines, un patient parcourt un programme dense : thérapies, consultations médicales, entraînements de groupe, repas, offres de temps libre, documents et objectifs, répartis dans les pièces et les étages, avec un plan qui change à bref délai. De l’intérieur, le séjour n’est pas un processus médical. C'est un calendrier que vous devez respecter.
02 · Le problème
Lorsque le plan change, chaque transfert est manuel : le thérapeute replanifie, le patient demande, la réception répond, la liste est réimprimée.
Des observations enregistrées pendant le séjour de part et d'autre, patients et personnel, et utilisées comme point de départ du concept.
03 · L'idée produit
Le concept mappe chaque friction observée en une seule réponse numérique et place la journée du patient au centre du système.
| Observation dans la routine quotidienne | Idée de solution numérique |
|---|---|
| Les plans de thérapie changent fréquemment | Un plan hebdomadaire numérique et toujours à jour |
| Les patients n'arrêtent pas de demander où se trouve une chambre | Salle et étage affichés à chaque session, avec une carte de navigation |
| Incertitude sur les vêtements et le matériel | Quoi porter et quoi apporter, par séance |
| Le temps libre est difficile à planifier | Aperçu des créneaux gratuits et des offres optionnelles |
| Beaucoup de papier | Informations numériques au lieu d'impressions |
04 · Comment ça marche
Ma journée et ma semaine : séances avec chambre, quoi porter et quoi apporter, check-in le matin, repas, offres de temps libre, objectifs, documents, actualités et une carte de navigation.
Le plus complet ; plusieurs parties sont une interface utilisateur sur des données statiques.Séances d'aujourd'hui avec les participants, numérisation QR pour la présence, mises à jour de la clinique, occupation des cabines et plan des installations.
Les horaires et les cabines sont des données statiques ; la présence reste dans le navigateur.Liste des patients et création via l'API, détails du patient avec une connexion QR imprimable, ainsi qu'un tableau de bord pour les stations, les plans de thérapie, les repas, les chambres et les analyses.
Le patient CRUD est réel ; le tableau de bord est constitué de données fictives.05 · Expérience patient
L'idée centrale
Chaque séance comporte sa salle, une ligne d'avantages, une liste de vêtements et une liste d'équipement. Sur le backend, il s'agit de champs validés sur l'enregistrement du planning, et non de texte libre. Il répond à la question que se pose réellement un patient à 8h45 : de quoi ai-je besoin pour la séance de 9h00 et comment puis-je y arriver.
Également dans l'espace patient : choix de menu hebdomadaire avec date limite de verrouillage, objectif de poids avec plage d'IMC, réservation de temps libre, documents de cours par diagnostic, actualités de la clinique et plan d'étage. Ceux-ci fonctionnent sur des données statiques et sur l’état du navigateur.
06 · Expérience en clinique
Orientation des deux côtés
Les patients obtiennent un itinéraire vers leur chambre à partir des détails de la séance ; les thérapeutes voient quelle cabine est libre, réservée ou occupée en ce moment. Les deux vues indiquent le même modèle de pièce et de cabine.
07 · Modèle de données et de système
Quatre entités sont conservées par le backend ; le reste du domaine est tapé sur le frontend et alimenté par des appareils statiques. La scission est exactement là où se termine le prototype et où le produit commencerait.
Relations : l'horaire, la présence et l'enregistrement font référence à un patient ; La présence fait référence à un horaire. Environ quatre-vingt-dix interfaces TypeScript décrivent le domaine frontend, compilé en mode strict.
08 · Ingénierie
Surface de l'API
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| Zone | Dans le prototype | Requis avant utilisation clinique |
|---|---|---|
| Authentification | Recherche de code dans un fichier JSON servi ; L'ID du patient est l'identifiant | Identité réelle, sessions, rôles et consentement |
| Persistance | JSON fichiers sur disque, pas de verrouillage ; la plupart des états dans le navigateur | Une base de données avec migrations, sauvegardes et location |
| Protection des données | Pas de cryptage, pas de journal d'audit, pas de règles de conservation | Processus RGPD, piste d'audit, droits de suppression et d'accès |
| Intégration | Données sur les appareils ; aucun système clinique connecté | Interfaces avec les systèmes de planification, de SIS et de documentation |
| Réglementaire | Non évalué | Examen de la classification des dispositifs médicaux, examen de la sécurité, accessibilité |
| Validation clinique | Aucun ; jamais utilisé par les patients ou le personnel | Pilote avec les intervenants cliniques, résultats mesurés |
09 · De l'expérience au prototype
Participation quotidienne à un programme de réadaptation; conversations avec d'autres patients, thérapeutes et membres du personnel ; regarder les routines.
Plans papier, changements à court terme, problèmes d'orientation, incertitude vestimentaire, pas de vue d'ensemble hebdomadaire ; charge de coordination élevée pour le personnel.
Le séjour des patients, les séances, les présences, les enregistrements, les repas, les cabines et les chambres, avec l'usure et les apports de chaque séance.
Un plan hebdomadaire axé sur le patient avec une vue quotidienne et des vues des rôles pour les thérapeutes et l'administration sur les mêmes données.
RehaConnect en janvier 2026, le soir et le week-end, avec des données de test uniquement, en tant que prototype local fonctionnel.
Présenté comme un concept de numérisation aux organismes de réadaptation, encadré pour le parcours de projet modèle DRV avec la clinique comme candidate.
10 · Que s'est-il passé ensuite
Le concept a été proposé aux organismes de réadaptation. Il n’a pas été déployé en production et le prototype n’a jamais été utilisé en opération clinique.
C’est la forme normale de la numérisation des soins de santé. Construire le logiciel n’en est qu’une partie. L'adoption nécessite également une capacité institutionnelle, une voie de financement et d'approvisionnement, une intégration avec les systèmes cliniques existants, un examen de la réglementation et de la sécurité, un changement organisationnel et un alignement avec les parties prenantes cliniques. Aucun de ces problèmes n’est résolu par un prototype, aussi complet soit-il.
11 · Ce que j'ai appris
Table de vérité
Toutes les captures d'écran de cette page proviennent du prototype exécuté localement sur un ensemble de données entièrement synthétiques (patiente fictive « Anna Meier », clinique fictive « Reha-Zentrum Waldsee »). Aucune clinique, patient ou membre du personnel n’est identifié.