Retour aux Études de Cas
healthcareAccès Complet Débloqué

Un Formulaire de Commande de Fournitures Patient qui Résiste à un Audit de Sécurité

Le personnel clinique commande des fournitures pour des patients nommés. Un simple formulaire web devient alors un système de données de santé, soumis au RGPD et à un audit de sécurité — là où échouent la plupart de ces formulaires.

Fabricant mondial de dispositifs médicaux · approvisionnement patients EMEA

healthcare
3
supply Lines
GDPR
patient Data
0
passwords

!Le Besoin

Commander des consommables pour un dispositif médical implanté ou porté n’est pas un panier d’achat. Chaque ligne est une référence catalogue liée à une thérapie précise — le dispositif, ses réservoirs, ses capteurs — et chaque commande nomme un patient, sa date de naissance, sa date de formation et, à l’arrêt de la thérapie, le motif. Ces données sont des données de santé sur une personne identifiée : elles relèvent du RGPD dans chaque marché EMEA desservi et doivent passer l’audit de sécurité du fabricant avant d’approcher la production. La version initiale s’authentifiait sur la plateforme d’identité du groupe, faisant de chaque promotion d’environnement un ticket dans un processus interne de plusieurs semaines.

L'Approche

Nous avons modélisé la commande autour des références catalogue plutôt que du texte libre : les trois lignes — dispositif, réservoirs, capteurs — portent chacune leur référence et leur quantité et ne peuvent être saisies en quelque chose d’inexistant. Identité du patient, date de naissance, date de formation et motif de fin de thérapie sont validés au niveau du schéma, le motif d’arrêt proposant un ensemble défini plus un champ libre, pour ne pas forcer les situations cliniques réelles dans la mauvaise case. Le formulaire est multilingue, car l’EMEA n’est pas un marché unique. Chaque envoi produit un PDF que le clinicien vérifie avant tout départ, plus une vue récapitulative, et la commande finalisée part par e-mail au lieu d’attendre dans une base que quelqu’un la remarque. Nous avons ensuite remplacé la dépendance à l’identité d’entreprise par une authentification par lien magique : aucun mot de passe créé, stocké ni transmis — et une passerelle de messagerie qui pré-charge les liens (le scanner ouvrant l’e-mail avant l’humain) a été traitée explicitement plutôt que découverte en production.

Technologies Utilisées

Next.jsTypeScriptSupabasePasswordless magic-link authZodPDF generation

La Livraison

Trois lignes de fourniture commandées par référence catalogue et quantité — dispositif, réservoirs et capteurs — plutôt que par description libre
Nom du patient, date de naissance, date de formation et motif de fin de thérapie validés au niveau du schéma
Un ensemble défini de motifs d’arrêt plus un champ libre, pour ne pas forcer les cas cliniques réels vers l’option la plus proche
Un formulaire multilingue, car l’EMEA regroupe plusieurs marchés et non un seul
Un PDF produit à chaque envoi pour vérification par le clinicien, plus une vue récapitulative avant tout départ
Commandes finalisées livrées par e-mail plutôt que laissées en base en attente d’être remarquées
Authentification sans mot de passe par lien magique, avec traitement explicite des passerelles de messagerie qui pré-chargent les liens

L'Impact

Les données patient sont minimisées par conception : le formulaire collecte ce dont la commande a réellement besoin, et rien d’autre
Aucun mot de passe n’est créé, stocké ni transmis dans le flux — l’identifiant le plus sûr est celui qui n’existe pas
Un modèle par référence empêche une commande de décrire un article absent du catalogue
Le clinicien voit le PDF avant envoi : l’erreur est interceptée par la personne qui connaît le patient
Supprimer la dépendance à l’identité d’entreprise a sorti la promotion d’environnement d’une file de tickets interne de plusieurs semaines
L’audit de sécurité dispose d’un récit précis et vérifiable plutôt que d’une assurance générale

Prêt à obtenir des résultats similaires?

Contactez-nous
Supalabs AI solutions