Healthcare PHI Compliance Patterns

Sélectionné par Skill Harbor : des patterns de conformité pour protéger les données des patients et des cliniciens dans les applications de santé, avec la contribution du Dr Keyur Patel (Health1 Super Speciality Hospitals). La protection fonctionne sur trois couches : classification (qu'est-ce qui est sensible), contrôle d'accès (qui peut le voir), et audit (qui l'a vu). Le PHI est défini comme toute donnée pouvant identifier un patient et liée à sa santé, des noms et identifiants nationaux aux diagnostics, médicaments et détails de réclamations. Le contrôle d'accès utilise la sécurité au niveau des lignes avec des politiques par établissement et des journaux d'audit en insertion seule, infalsifiables. L'étiquetage de schéma marque les colonnes PHI et PII au niveau de la base de données. La partie la plus pratique est le catalogue des vecteurs de fuite courants : données patient dans les messages d'erreur renvoyés au client, objets patient complets dans la sortie console, données identifiantes dans les paramètres d'URL, PHI dans le localStorage du navigateur, clés service_role dans le code côté client, et dossiers patients complets dans les logs et le suivi d'erreurs. Chacun vient avec l'alternative sûre, comme des UUID opaques au lieu de numéros de dossier médical et des erreurs génériques avec journalisation côté serveur. Une checklist de déploiement conclut le skill : pas de PHI dans les erreurs, logs, URLs ou stockage navigateur, RLS activé sur toutes les tables PHI, pistes d'audit actives, isolation inter-établissements vérifiée. Par @affaan-m, listé ici avec crédit à son créateur et contributeur. Tiré du dépôt affaan-m/ECC (MIT). Bémols honnêtes : les patterns ne rendent pas une appli conforme HIPAA ou RGPD à eux seuls, une vraie revue de conformité est requise ; ne mettez jamais de vraies données patient dans un chat en l'utilisant ; c'est un guide de développement, pas un avis juridique. Skill Harbor ne vérifie jamais le code, examinez-le vous-même avant usage.