Conformité HIPAA

Que fait Conformité HIPAA ?

Utilisez ce skill comme point d'entrée spécifique à la HIPAA lorsqu'une tâche porte clairement sur la conformité des soins de santé aux États-Unis. Ce skill reste volontairement léger et canonique :

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

Quand l'utiliser

• La demande mentionne explicitement la HIPAA, les PHI, les entités couvertes, les associés commerciaux ou les BAA.
• Construction ou révision de logiciels de santé américains qui stockent, traitent, exportent ou transmettent des PHI.
• Évaluation de si les logs, les analyses, les prompts LLM, le stockage ou les workflows de support créent une exposition HIPAA.
• Conception de systèmes orientés patients ou cliniciens où l'accès minimum nécessaire et l'auditabilité sont importants.

Comment ça fonctionne

Traitez la HIPAA comme une surcouche sur le skill de confidentialité des soins de santé plus large :

1. Commencez par healthcare-phi-compliance pour les règles d'implémentation concrètes.
2. Appliquez les portes de décision spécifiques à la HIPAA :
   • Ces données sont-elles des 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 aux données ?
   • L'accès est-il limité à la portée minimum nécessaire ?
   • Les événements de lecture/écriture/exportation sont-ils audités ?
3. Passez à healthcare-reviewer si la tâche affecte la sécurité des patients, les workflows cliniques ou une architecture de production réglementée.

Garde-fous spécifiques à la HIPAA

• Ne placez jamais de PHI dans les logs, les événements d'analyse, les rapports de crash, 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 exemples de charges utiles copiés.
• Exigez un accès authentifié, une autorisation limitée et des pistes d'audit pour les lectures et écritures de PHI.
• Considérez les fournisseurs SaaS, d'observabilité, d'outillage de support et de LLM comme bloqués par défaut jusqu'à ce que le statut BAA et les limites de données soient clairs.
• Suivez le principe d'accès minimum 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, NIP, numéros de téléphone, adresses ou autres identifiants.

Exemples

Exemple 1 : Demande produit cadré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 à la HIPAA.

Modèle de réponse :

• Activez hipaa-compliance
• Utilisez healthcare-phi-compliance pour examiner le mouvement des PHI, les logs, 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
• Passez à healthcare-reviewer si les résumés influencent les décisions cliniques

Exemple 2 : Décision fournisseur/outillage

Demande utilisateur :

Pouvons-nous envoyer les transcripts de support et les messages des patients dans notre stack analytique ?

Modèle de réponse :

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

Compétences connexes

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