conformité-hipaa

Conformité HIPAA

Utilisez ceci comme point d'entrée spécifique à HIPAA lorsqu'une tâche concerne clairement la conformité américaine en matière de santé. Ce skill reste intentionnellement mince et canonique :

• healthcare-phi-compliance reste le skill d'implémentation principal pour la gestion des PHI/PII, la classification des données, la journalisation d'audit, le chiffrement et la prévention des fuites.
• healthcare-reviewer reste le réviseur spécialisé lorsque le code, l'architecture ou le comportement du produit nécessite une seconde passe sensible au domaine de la santé.
• security-review s'applique toujours pour l'authentification générale, la gestion des entrées, les secrets, l'API et le durcissement du déploiement.

Quand l'utiliser

• La demande mentionne explicitement HIPAA, PHI, les entités couvertes, les associés commerciaux ou les BAAs
• Construire ou réviser un logiciel de santé américain qui stocke, traite, exporte ou transmet des PHI
• Évaluer si la journalisation, les analyses, les prompts LLM, le stockage ou les workflows de support créent une exposition HIPAA
• Concevoir des systèmes destinés aux patients ou aux cliniciens où l'accès minimal nécessaire et l'auditabilité sont importants

Comment ça fonctionne

Traitez HIPAA comme une surcouche au-dessus du skill plus large de confidentialité des soins de santé :

1. Commencez par healthcare-phi-compliance pour les règles d'implémentation concrètes.
2. Appliquez les portes de décision spécifiques à HIPAA :
   • Cette donnée est-elle une PHI ?
   • Cet acteur est-il une entité couverte ou un associé commercial ?
   • Un fournisseur ou un modèle nécessite-t-il un BAA avant de toucher les données ?
   • L'accès est-il limité à la portée minimale nécessaire ?
   • Les événements de lecture/écriture/export sont-ils audités ?
3. Élevez à healthcare-reviewer si la tâche affecte la sécurité des patients, les workflows cliniques ou l'architecture de production réglementée.

Garde-fous spécifiques à HIPAA

• Ne placez jamais de PHI dans les logs, les événements d'analyse, les rapports d'incidents, les prompts ou les chaînes d'erreur visibles par le client.
• N'exposez jamais de PHI dans les URL, le stockage du navigateur, les captures d'écran ou les charges utiles d'exemple copiées.
• Exigez un accès authentifié, une autorisation limitée et des pistes d'audit pour les lectures et écritures de PHI.
• Traitez les SaaS tiers, l'observabilité, les outils de support et les fournisseurs LLM comme bloqués par défaut jusqu'à ce que le statut BAA et les limites des données soient clairs.
• Suivez le principe d'accès minimal nécessaire : le bon utilisateur ne doit voir que la plus petite partie de PHI nécessaire à la tâche.
• Préférez les identifiants internes opaques aux noms, NIPs, numéros de téléphone, adresses ou autres identifiants.

Exemples

Exemple 1 : Demande produit formulée comme HIPAA

Demande utilisateur :

Ajoutez des résumés de visites générés par IA à notre tableau de bord clinique. Nous servons des cliniques américaines et devons rester conformes à HIPAA.

Modèle de réponse :

• Activez conformité-hipaa
• Utilisez healthcare-phi-compliance pour vérifier le mouvement des PHI, la journalisation, le stockage et les limites des prompts
• Vérifiez que le fournisseur de résumé est couvert par un BAA avant d'envoyer des PHI
• Élevez à healthcare-reviewer si les résumés influencent des décisions cliniques

Exemple 2 : Décision de fournisseur/outil

Demande utilisateur :

Pouvons-nous envoyer les transcriptions du support et les messages des patients dans notre stack d'analyse ?

Modèle de réponse :

• Supposez que ces messages peuvent contenir des PHI
• Bloquez la conception à moins que le fournisseur d'analyse ne soit approuvé pour les charges de travail liées à HIPAA et que le chemin de données soit minimisé
• Exigez une rédaction ou un modèle d'événement non-PHI lorsque c'est possible

Skills associés

• healthcare-phi-compliance
• healthcare-reviewer
• healthcare-emr-patterns
• healthcare-eval-harness
• security-review