Étude de cas · SHCA Health Providers

Création d’un SaaS de gestion de patients multi-établissements conforme aux principes HIPAA pour un groupe américain de soins aux aînés — Next.js + Django + PostgreSQL sur AWS

Comment UnlockLive a remplacé un patchwork de feuilles de calcul, de notes papier et d’outils DME déconnectés dans 5 établissements pour aînés par une plateforme unique, alignée HIPAA et multi-tenant, en Next.js + Django + PostgreSQL sur AWS — réduisant de 70 % le temps de saisie des notes cliniques, triplant la vitesse d’admission et offrant à l’exploitant une source de vérité prête pour l’audit dès le premier jour.

  • SecteurSaaS santé / soins aux aînés
  • Année2024
  • PaysÉtats-Unis
  • Durée6 mois
Building a HIPAA-Aligned Multi-Facility Patient Management SaaS for a US Senior-Care Group — Next.js + Django + PostgreSQL on AWS hero screenshot

Résultats en un coup d'œil

  • 70%Réduction du temps moyen de saisie des notes cliniques (18+ min → moins de 5)
  • 3xAdmission des patients plus rapide dans les 5 établissements
  • 100%Prêt pour l’audit : chaque lecture/écriture/export consigné dans un journal en ajout seul
  • 5Établissements de soins aux aînés opérationnels dès le premier jour de la mise en production

Le défi

SHCA gérait des dizaines d’établissements pour aînés avec un patchwork de feuilles Excel, de notes de quart sur papier et de trois outils de type DME déconnectés — sans source de vérité unique pour aucun patient. Les infirmières ressaisissaient les mises à jour dans plusieurs systèmes à chaque quart, les familles n’avaient aucune visibilité, les administrateurs ne pouvaient pas prouver qui avait vu quoi, et l’intégration d’un nouvel établissement signifiait recréer le même fragile modèle Excel.

La demande était sans compromis : livrer un SaaS de gestion des patients multi-établissements, aligné HIPAA, sur lequel toute infirmière, tout médecin, administrateur ou membre de la famille pouvait se connecter en toute sécurité dès le premier jour — avec des notes cliniques basées sur des modèles, un accès aux dossiers par rôle, des pistes d’audit complètes et la possibilité d’intégrer un tout nouvel établissement en quelques minutes plutôt qu’en semaines. Moins que « un dossier, un journal, une source de vérité » aurait livré le même problème de fragmentation sous un meilleur habillage.

Notre solution

Nous avons construit un SaaS multi-tenant Next.js + Django + PostgreSQL hébergé sur AWS, où chaque patient existe dans un seul dossier et où chaque action est observable, auditable et limitée par rôle.

Le backend Django expose une API Django REST Framework avec une frontière stricte entre locataires — chaque requête est filtrée par `facility_id` au niveau de l'ORM, de sorte qu'un infirmier de l'établissement A ne peut littéralement pas faire un SELECT sur un patient de l'établissement B, même avec une URL falsifiée. L'authentification par JWT relie quatre rôles (médecin, infirmier, administrateur, famille) à des permissions par endpoint et par champ, et un unique journal en ajout seul « audit_event » consigne chaque lecture, écriture et export avec `(user_id, role, facility_id, patient_id, action, timestamp, ip)`, afin de pouvoir produire en quelques secondes un audit conforme à HIPAA pour n'importe quel patient sur n'importe quelle période.

Les notes cliniques — le flux de travail à plus forte valeur du produit — reposent sur des modèles. Au lieu de saisir librement une note SOAP de 20 minutes, l'infirmier choisit un modèle, ne renseigne que les différences, et le système sérialise une note structurée accompagnée d'un résumé lisible. Des champs de texte adaptés à la saisie vocale, un enregistrement automatique toutes les 5 secondes et des instantanés de médication / de constantes vitales joignables réduisent le temps moyen de rédaction d'une note de plus de 18 minutes à moins de 5.

Le front-end Next.js propose une expérience unique de type SPA pour tous les rôles, avec une navigation adaptée au rôle, des mises à jour optimistes des patients et un sélecteur d'établissement interne pour les administrateurs qui gèrent plusieurs sites. Les membres de la famille disposent d'un portail strictement cloisonné — ils ne voient que le patient auquel ils sont rattachés, et uniquement les champs que le médecin a approuvés pour le partage.

Côté infrastructure : PostgreSQL sur RDS avec restauration à un instant donné automatisée, S3 avec pièces jointes chiffrées par KMS et URL signées à durée limitée (aucune URL S3 brute dans la nature), CloudWatch + Sentry sur chaque endpoint, vérification nocturne automatisée des sauvegardes, et infrastructure as code pour pouvoir déployer une seconde région sans ouvrir de ticket auprès de l'équipe cloud.

  • Dossiers patients multi-locataires avec une frontière `facility_id` stricte appliquée au niveau de l'ORM Django (l'accès entre établissements est impossible, et pas simplement improbable)
  • Accès limité par rôle pour le médecin, l'infirmier, l'administrateur et la famille — contrôlé à la fois au niveau de l'endpoint et du champ
  • Notes cliniques basées sur des modèles avec enregistrement automatique, constantes vitales/médicaments joignables et résumé lisible stocké avec le JSON structuré
  • Journal `audit_event` en ajout seul sur chaque lecture, écriture et export, interrogeable par patient sur n'importe quelle période — conforme à HIPAA dès le départ
  • Portail famille avec partage au niveau des champs approuvé par le médecin, pièces jointes via URL signées à durée limitée et périmètre d'accès par patient
  • Console d'administration multi-établissements : intégrez un nouvel établissement, attribuez les rôles et réaffectez les patients sans modification de code
  • Infrastructure AWS renforcée : restauration à un instant donné RDS, chiffrement S3 + KMS, CloudWatch + Sentry, vérification nocturne des sauvegardes, infrastructure as code

Comment nous l'avons construit

  1. 01

    Découverte, modèle de menaces, conception de données multi-établissements

    Nous avons commencé par suivre des infirmières pendant un vrai quart de travail et par cartographier chaque endroit où circulent les données patients : papier, Excel, DME, messagerie de groupe, télécopie. À partir de là, nous avons mené une modélisation des menaces axée sur HIPAA pour les quatre modes de défaillance les plus risqués : fuite entre établissements, exportations non suivies, partage excessif avec la famille et URL de pièces jointes non signées. Il en est ressorti les trois ancrages architecturaux sur lesquels repose le reste du projet : des requêtes limitées au tenant et appliquées au niveau de l’ORM, un journal audit_event en ajout seul pour chaque action, et des URL S3 signées sans aucun accès direct aux objets.

  2. 02

    API Django REST + modèle de données multi-tenant PostgreSQL

    Nous avons modélisé les établissements, les patients, les rôles et les notes cliniques dans un seul schéma PostgreSQL, avec une frontière stricte `facility_id` intégrée à chaque QuerySet via un gestionnaire limité au tenant. Les rôles (médecin, infirmier, administrateur, famille) contrôlent à la fois les endpoints et les champs : un utilisateur famille ne peut même pas voir qu’un champ « medications » existe dans la réponse, sauf si le médecin a activé le partage. Les notes cliniques sont pilotées par des modèles et stockées en JSON structuré accompagné d’un résumé lisible généré, ce qui garde les rapports et les exportations propres.

  3. 03

    UX SPA Next.js, navigation selon les rôles, portail famille

    Nous avons livré une SPA Next.js unique qui change d'apparence selon le rôle à la connexion : une infirmière voit la file de garde et le flux de notes rapides ; un administrateur voit le sélecteur d'établissement et la recherche d'audit ; un membre de la famille ne voit que son patient lié, avec le sous-ensemble de champs approuvé par le médecin. Mises à jour optimistes, enregistrement automatique des brouillons de notes et sélecteur de modèles à faible friction ont fait passer le flux très fréquent « ajouter une note » de plus de 18 minutes à moins de 5.

  4. 04

    Durcissement AWS, audit, observabilité, transfert

    Nous avons déployé la plateforme sur AWS (EC2 + RDS PostgreSQL + S3 + KMS), avec CloudWatch + Sentry sur chaque point d'accès, vérification nocturne des sauvegardes et infrastructure as code. Chaque lecture, écriture et export alimente un journal audit_event en ajout seul, de sorte qu'un auditeur peut obtenir en quelques secondes un rapport d'activité par patient. Nous avons remis à l'opérateur un guide d'exploitation pour l'intégration des établissements, l'attribution des rôles et la réponse aux incidents, et sommes restés disponibles sous contrat pour des évolutions mensuelles.

Stack technique

  • Next.js (React)
  • Django
  • Django REST Framework
  • PostgreSQL
  • Celery + Redis (tâches en arrière-plan)
  • AWS (EC2, RDS, S3, CloudWatch)
  • AWS KMS (chiffrement au repos)
  • Accès par rôle Auth0 / JWT
  • Sentry + CloudWatch (observabilité)
  • Docker
  • Développement de logiciels sur mesure
  • Ingénierie SaaS pour la santé
  • Design UI/UX
  • Architecture cloud
  • DevOps et observabilité
  • Cybersécurité
“Nous avions un projet vaste et complexe, avec plusieurs bases de données devant communiquer entre elles. L’équipe UnlockLive a posé les bonnes questions de suivi, tenu un calendrier honnête et livré quelque chose que notre personnel clinique utilise réellement tous les jours.”
Sofia Abdelkafi · Consultant santé et bien-être

Questions fréquentes

Comment construire un SaaS de santé multi-tenant sans fuite de données patients entre établissements ?

Nous appliquons la frontière entre locataires au niveau de l'ORM Django, et non dans les gestionnaires de routes. Chaque modèle qui touche des PHI est précédé d'un gestionnaire de QuerySet limité au locataire, qui filtre sur `facility_id` issu du JWT avant tout autre filtre. Résultat : une URL falsifiée, un `if` oublié dans une vue ou un bug dans un sérialiseur ne peut pas renvoyer des dossiers d'un autre établissement, car le SQL vu par la base de données est déjà filtré. Nous y associons des permissions au niveau des champs, afin qu'un membre de la famille ne puisse littéralement pas voir qu'un champ sensible existe dans la réponse.

La plateforme SHCA est-elle conforme à HIPAA ?

Nous avons conçu l'application avec des contrôles alignés sur HIPAA : accès limité par rôle, chiffrement au repos (RDS + S3 + KMS) et en transit (TLS 1.2+), journal `audit_event` en ajout seul pour chaque lecture, écriture ou export de PHI, URL signées et limitées dans le temps pour chaque pièce jointe, et vérification nocturne des sauvegardes. La conformité HIPAA repose en définitive sur un Business Associate Agreement et un programme organisationnel, que l'opérateur pilote, mais la plateforme a été conçue pour qu'un audit HIPAA puisse être traité par une requête, et non par une refonte d'architecture.

Combien de temps a pris la construction de SHCA, et comment le calendrier était-il structuré ?

Six mois de bout en bout. En gros : 3 semaines de découverte, de modélisation des menaces et de conception des données ; 14 semaines de développement de l'API Django REST + de la SPA Next.js en sprints de deux semaines, avec tests automatisés sur chaque PR et revue de sécurité avant la mise en production ; 4 semaines de durcissement AWS, d'observabilité, de travail sur le journal d'audit et de formation des cliniciens ; 4 semaines de pilote avec un établissement, suivies d'un déploiement la même semaine dans les 4 autres établissements.

Quelle pile technologique alimente la plateforme de gestion des patients SHCA ?

Un front-end SPA Next.js (React), une API Django + Django REST Framework, PostgreSQL sur Amazon RDS, S3 + KMS pour les pièces jointes chiffrées, Celery + Redis pour les tâches d'arrière-plan, une authentification par JWT avec permissions par rôle au niveau de chaque point d'accès et de chaque champ, et CloudWatch + Sentry pour l'observabilité, le tout conteneurisé avec Docker et déployé par infrastructure as code sur AWS.

La plateforme peut-elle passer à l'échelle de dizaines d'établissements ou être redéfinie visuellement pour un autre opérateur de soins aux aînés ?

Oui : le modèle de données et le système de permissions sont indépendants de l'établissement par conception. Ajouter un établissement est une action d'administration, et non une modification de code ; un nouvel opérateur peut redéfinir l'identité visuelle du front-end et réutiliser le même backend multi-locataire. La même architecture (frontière `facility_id` + journal audit_event + pièces jointes en URL signées) est réutilisable pour tout SaaS multi-locataire proche de HIPAA : cliniques, groupes de santé comportementale, agences de soins à domicile, etc.

Envie d'un résultat comme celui-ci ?

Parlez à l'équipe qui a construit Création d’un SaaS de gestion de patients multi-établissements conforme aux principes HIPAA pour un groupe américain de soins aux aînés — Next.js + Django + PostgreSQL sur AWS. Nous définirons le périmètre de votre projet, vous remettrons une proposition à prix fixe et vous présenterons l'exemple le plus proche de notre portfolio.

Réserver un appel stratégique