Les ingénieurs qui abordent leur premier client dans le secteur de la santé imaginent souvent HIPAA comme un audit de code géant. Ce n'est généralement pas le cas. La Règle de sécurité est un ensemble de mesures de sécurité administratives, physiques et techniques. La majeure partie d'un programme HIPAA repose sur l'analyse des risques, les politiques, le personnel et les contrats avec les fournisseurs. Seule une partie est déterminée par ce que votre code fait, et savoir quelle partie rend l'ensemble moins mystérieux.
Cette page traite de cette partie liée au code. Elle ne constitue pas une détermination d'entité couverte, un BAA, ni une promesse que heygrc ou ISMS Copilot gère les ePHI.
Les mesures de sécurité qui concernent le code
Les mesures de sécurité techniques se trouvent dans le 45 CFR 164.312. Celles qui changent réellement dans une demande de fusion sont l'identification unique des utilisateurs (164.312(a)(2)(i)), l'accès d'urgence (164.312(a)(2)(ii)), la déconnexion automatique (164.312(a)(2)(iii)), le chiffrement et le déchiffrement (164.312(a)(2)(iv)), les contrôles d'audit (164.312(b)), l'intégrité (164.312(c)(1)), l'authentification de la personne ou de l'entité (164.312(d)) et la sécurité de transmission (164.312(e)(1)). La déconnexion automatique et le chiffrement/déchiffrement sont des spécifications adressables : implémentez-les lorsque c'est raisonnable et approprié, ou documentez pourquoi ce n'est pas le cas et utilisez une mesure équivalente. Si vous pouvez raisonner sur qui peut accéder aux ePHI, si l'activité est enregistrée, si elle est chiffrée au repos et en transit, et si une modification authentifie toujours l'appelant, vous raisonnez sur la majeure partie de la surface liée au code de la Règle de sécurité.
Beaucoup de ce qui semble lié à HIPAA en ingénierie se situe en dehors de la diff : les revues d'accès, la formation du personnel, une analyse des risques et un BAA signé lorsque les règles des associés commerciaux s'appliquent (ce dernier est un contrat obligatoire, pas seulement une preuve qu'un processus a été exécuté). Le code lui-même concerne principalement le 164.312.
Les modifications qui deviennent des constats
Une demande de fusion qui journalise un corps de requête complet contenant des données de patients peut placer des ePHI dans un stockage accessible à plus de personnes que le système d'enregistrement. Une modification qui supprime le chiffrement d'un stockage d'enregistrements, ou qui achemine chaque accès via un compte de service partagé, appartient à la même catégorie de problème : la mesure de sécurité est plus faible après la fusion qu'avant. Si elle est détectée dans la PR, l'auteur a encore le contexte pour la corriger. Si elle est détectée lors d'une revue de sécurité client ou d'une enquête, il s'agit d'une remédiation avec une traçabilité écrite.
Cette asymétrie est l'argument pour vérifier la surface 164.312 dans la diff plutôt que de la découvrir après qu'un client a demandé des preuves.
Où heygrc s'intègre, et la limite d'honnêteté
heygrc est conçu pour reconnaître ces formes lorsque HIPAA est l'un des frameworks que vous avez sélectionnés, et pour citer la mesure de sécurité à la clause. Il ne détermine pas si vous êtes une entité couverte ou un associé commercial, ne rédige pas votre analyse des risques, ne signe pas de BAA, ni ne stocke des ePHI. Ni heygrc ni ISMS Copilot ne sont des associés commerciaux HIPAA pour les données de vos clients dans ce produit. Utilisez-le comme un réviseur de la modification, et non comme un programme de conformité.