Collecte de formulaires conforme HIPAA

« Conforme HIPAA » est placardé sur les pages marketing de presque tout constructeur de formulaires ciblant les États-Unis. C'est aussi l'une des expressions les plus utilisées à la légère du secteur. Aucun organisme gouvernemental n'émet de tampon HIPAA. Aucun produit ne peut se rendre « conforme HIPAA » à lui seul — la conformité est une propriété de la façon dont une entité couverte utilise un outil, pas une propriété livrée avec l'outil. Et plusieurs des affirmations techniques derrière la phrase sont plus minces qu'elles n'en ont l'air.

Ce guide s'adresse à toute personne exploitant un formulaire en ligne touchant à des Protected Health Information (PHI) sous le droit américain : cliniciens, pratiques de télémédecine, cabinets dentaires et orthodontiques, prestataires en santé mentale, professions paramédicales, services de facturation, et les équipes IT et conformité qui les soutiennent. Il détaille ce que HIPAA exige réellement des formulaires en ligne, ce qu'un Business Associate Agreement apporte et n'apporte pas, où le récit du chiffrement est honnêtement solide et où il est honnêtement gonflé, et comment évaluer le récit HIPAA d'un fournisseur sans prendre la copie marketing pour argent comptant.

Ce qu'est réellement HIPAA — un briefing court et honnête

HIPAA est le Health Insurance Portability and Accountability Act de 1996, plus les règlements pris par le Department of Health and Human Services — surtout la Privacy Rule, la Security Rule et la Breach Notification Rule. Ensemble, ils définissent comment les Protected Health Information doivent être traitées par certaines organisations régulées. Trois choses utiles d'emblée.

• HIPAA est une loi fédérale américaine. Elle ne régit pas directement les organisations suisses, UE ou britanniques — celles-ci suivent nLPD, RGPD et cadres nationaux équivalents. Les organisations internationales rencontrent HIPAA quand elles prennent en charge des données patient US ou collaborent avec des entités couvertes US.
• HIPAA couvre deux types d'organisations : « Covered Entities » (la plupart des prestataires de santé, plans de santé, clearinghouses) et « Business Associates » (fournisseurs traitant des PHI pour le compte d'une entité couverte). Les constructeurs de formulaires traitant des PHI pour une clinique agissent comme Business Associates.
• HIPAA définit ce qui est PHI précisément. Une PHI est une information de santé individuellement identifiable créée ou reçue par une entité couverte, sous toute forme. Les 18 « identifiants » — nom, dates, adresses, téléphones, e-mails, numéros de compte, IDs biométriques, etc. — sont la référence canonique de ce qui rend la donnée identifiable.

Les trois règles qui comptent pour les formulaires

1. La Privacy Rule

La Privacy Rule régit l'utilisation et la divulgation de PHI : qui peut les voir, ce qu'elles peuvent en faire, quelle autorisation un patient doit donner pour des usages non routiniers, quels droits il a sur ses informations (accès, rectification, registre des divulgations). Pour les formulaires en ligne, elle façonne ce que vous pouvez collecter (le minimum nécessaire), comment vous pouvez l'utiliser (uniquement les finalités communiquées) et quel avis vous devez donner (la Notice of Privacy Practices).

2. La Security Rule

La Security Rule s'applique spécifiquement aux PHI électroniques (ePHI) et est la règle la plus directement liée aux formulaires. Elle définit des garanties administratives, physiques et techniques que les entités couvertes et les business associates doivent mettre en œuvre. Elle distingue « required » et « addressable » — addressable ne veut pas dire optionnel, mais permet des alternatives à condition de documenter pourquoi la spécification standard n'est pas raisonnable et quelle mesure équivalente est en place.

3. La Breach Notification Rule

La Breach Notification impose aux entités couvertes et aux business associates d'informer patients, HHS et (au-delà d'un seuil) les médias en cas d'atteinte à des unsecured PHI. « Unsecured » est le mot clé : des PHI chiffrées selon les standards NIST sont considérées comme ne nécessitant pas de notification parce que techniquement illisibles. Le chiffrement n'est donc pas qu'un contrôle, c'est aussi une exception sécurisée pour la notification — raison opérationnelle majeure pour laquelle les programmes HIPAA réels s'appuient lourdement dessus.

Garanties techniques de la Security Rule applicables aux formulaires

Les garanties techniques sont rédigées à un niveau délibérément élevé — HHS veut que la règle traverse les évolutions technologiques. Les cinq catégories qui mordent le plus sur les constructeurs de formulaires sont ci-dessous.

Business Associate Agreements — ce qu'ils font réellement

Un Business Associate Agreement (BAA) est un contrat entre une entité couverte et un business associate qui répartit les responsabilités HIPAA et oblige le business associate à se conformer aux portions concernées des Privacy et Security Rules. Si un fournisseur de formulaires traite des PHI pour vous, vous ne pouvez pas légalement l'utiliser comme outil HIPAA-conforme sans BAA signé. C'est l'un des tests les plus simples : la revendication « conforme HIPAA » du fournisseur est-elle opérationnelle ou aspirative ?

Ce qu'un BAA fait :

• Établit que le fournisseur mettra en œuvre les garanties administratives, physiques et techniques de la Security Rule
• Définit les usages et divulgations autorisés des PHI par le fournisseur (uniquement pour le service contracté)
• Oblige le fournisseur à signaler incidents et violations de sécurité dans des délais spécifiés
• Oblige le fournisseur à obtenir des BAAs avec ses propres sous-traitants touchant les PHI
• Oblige le fournisseur à retourner ou détruire les PHI à la fin du contrat, ou à étendre les protections si retour/destruction n'est pas faisable

Ce qu'un BAA ne fait pas :

• Il ne rend pas à lui seul le fournisseur « conforme HIPAA » — celui-ci doit effectivement implémenter les garanties. Un BAA est nécessaire, pas suffisant.
• Il n'isole pas l'entité couverte de la responsabilité si le fournisseur faillit. HHS peut poursuivre les deux ; un BAA est en somme une trace écrite et une répartition interne du risque.
• Il ne couvre pas rétroactivement l'usage antérieur. « Nous avons utilisé Google Forms pendant deux ans, on signe maintenant » n'efface pas la période précédente non autorisée.
• Il n'étend pas HIPAA à travers les frontières. Un fournisseur non US qui signe un BAA doit toujours faire correspondre la réalité opérationnelle aux promesses — et un BAA n'exempte pas les parties du droit local de protection des données dans la juridiction du fournisseur.

Affirmations HIPAA courantes qui ne tiennent pas

1. « Nous sommes conformes HIPAA — voici notre certificat »

Il n'existe pas de certificat HIPAA gouvernemental. Les audits tiers de préparation et les certifications HITRUST existent et sont des proxies utiles, mais pas des approbations HHS. Un fournisseur qui vante un « certificat HIPAA » sans expliquer ce dont il s'agit est soit confus, soit espère que vous le serez.

2. « Google Forms gratuit est conforme HIPAA si vous avez un BAA »

Google signe des BAAs pour les comptes Workspace dans certaines éditions, mais le produit grand public Google Forms n'en fait pas partie. Des comptes Gmail personnels collectant des questionnaires de santé sont sans ambiguïté hors du BAA, et le fait que Google chiffre le trafic en transit n'y change rien. Confondre le produit grand public avec le produit entreprise éligible au BAA est une erreur fréquente et coûteuse.

3. « Chiffré en transit et au repos = conforme HIPAA »

TLS en transit et chiffrement de disque au repos sont des contrôles de base nécessaires. Ils satisfont, bien, deux spécifications addressable précises. Ils ne traitent ni le contrôle d'accès, ni l'audit, ni l'intégrité, ni l'authentification, ni les garanties administratives, ni les procédures de notification, ni les BAAs. « Chiffré » est un chapitre d'HIPAA, pas tout le livre.

4. « Nos formulaires sont chiffrés bout en bout, donc HIPAA ne s'applique pas vraiment »

Le chiffrement de bout en bout est un fort contrôle technique. Il ne change pas le statut juridique des données : l'ePHI reste de l'ePHI, chiffré ou non. Ce qu'il change, c'est l'analyse de notification : des ePHI chiffrées qui sont breachées peuvent ne pas exiger de notification patient parce qu'elles ne sont pas « unsecured » au sens HIPAA. C'est une vraie valeur — un bonus en plus du reste d'HIPAA, pas un remplacement.

5. « Notre hébergement à l'étranger est OK car nous suivons RGPD »

Conformité RGPD et conformité HIPAA sont des régimes distincts, avec définitions, recours et préoccupations transfrontalières différents. Un fournisseur suisse ou UE traitant des PHI US sous BAA est faisable — mais « nous suivons RGPD » n'est pas, à lui seul, une réponse HIPAA suffisante. La gestion transfrontalière de PHI ajoute une complexité (garanties contractuelles supplémentaires, considérations de résidence sous orientations HHS, coordination de notifications entre juridictions) à laquelle la plupart des fournisseurs étrangers ne sont pas actuellement préparés.

Mettre en place un formulaire en ligne conscient d'HIPAA en pratique

Quel que soit le fournisseur, le schéma opérationnel produisant un formulaire HIPAA-aware défendable est sensiblement le même.

Où le chiffrement de bout en bout s'inscrit dans un programme HIPAA

Le chiffrement de bout en bout zéro-connaissance n'est pas une exigence HIPAA, et aucun fournisseur ne devrait le prétendre. C'est en revanche un puissant complément au socle de contrôle HIPAA, pour des raisons qu'il vaut la peine d'exposer.

• Posture de notification : des ePHI chiffrées de sorte que le fournisseur ne puisse les déchiffrer satisfont nettement l'exclusion « unsecured » selon les orientations HHS — significativement plus fort qu'un chiffrement de disque au repos où le fournisseur garde les clés.
• Posture Privacy Rule : minimum nécessaire et limitation d'usage sont plus faciles à défendre quand le fournisseur ne peut structurellement pas lire les PHI, parce que l'accès incident du personnel ou des sous-traitants est techniquement empêché plutôt que contractuellement promis.
• Résistance aux subpoenas : un fournisseur qui ne peut physiquement pas déchiffrer les PHI ne peut pas produire des PHI lisibles sous subpoena. Atout pour les charges sensibles ; complication si la pratique elle-même a un jour besoin de la coopération du fournisseur en justice.
• Surface d'audit réduite : les revues HHS de business associates examinent si les garanties ont vraiment été implémentées. « Le fournisseur ne peut pas lire les PHI » est la réponse la plus forte à plusieurs questions techniques, et rend le BAA moins fictif.

Scénarios courants en santé US

Formulaires d'admission et d'antécédents

Pré-visite standard — démographie, assurance, antécédents, médicaments, allergies. PHI dès leur existence ; ils nécessitent l'ensemble des garanties techniques de la Security Rule. Les fournisseurs spécialisés santé proposent typiquement un BAA sur un palier payant ; vérifiez ce qui est inclus.

Onboarding et triage de télémédecine

Triage avant rendez-vous, questionnaires de symptômes, formulaires de type COVID. Volume potentiellement élevé ; données indubitablement PHI. La télémédecine est aussi un domaine où HHS a publié des orientations spécifiques, et où les régulateurs regardent comment les formulaires alimentent les systèmes en aval.

Authorization de divulgation de PHI

Formulaires autorisant la divulgation à un tiers — typiquement signés par le patient, souvent requis par écrit sous la Privacy Rule. Le formulaire est métadonnée d'une action patient à enjeu ; l'autorisation signée est elle-même PHI. La journalisation de qui a vu et exporté l'autorisation compte autant que le contenu.

Admissions en santé mentale et comportementale

PHI particulièrement sensibles : diagnostics psychiatriques, divulgations de consommation, dépistages de suicidalité. Les informations comportementales sont soumises à des contraintes additionnelles sous 42 CFR Part 2 aux USA, en plus d'HIPAA. L'histoire du chiffrement importe ici plus qu'ailleurs.

Facturation, paiement et formulaires de difficultés financières

Ils collectent PHI plus financier. PCI-DSS chevauche HIPAA sur la partie carte. Gardez les flux carte et PHI séparés : les paiements passent par un PSP, les PHI par la couche formulaire — sans mélange.

Recherche et collecte gouvernée par IRB

Les données de recherche peuvent être PHI, soumises à la Common Rule, et exiger un consentement approuvé par IRB. L'interaction HIPAA-recherche est un sujet à part ; le formulaire est rarement la partie la plus dure, mais il doit s'insérer proprement dans le protocole et le flux de consentement IRB.

Liste de contrôle avant ouverture d'un formulaire HIPAA-pertinent

1. Avez-vous confirmé que les données sont des PHI sous HIPAA et que vous opérez comme entité couverte ou business associate ?
2. Le fournisseur veut et peut-il signer un Business Associate Agreement couvrant le produit et le palier utilisés ?
3. Les comptes admin sont-ils nommés uniquement, MFA-activés et soumis au provisioning/deprovisioning ?
4. Les soumissions sont-elles chiffrées en transit (TLS) et au repos ? Si du bout en bout est disponible, l'utilisez-vous ?
5. Le fournisseur produit-il un journal d'actions admin sur les soumissions, et pouvez-vous le récupérer à la demande ?
6. Avez-vous appliqué le minimum nécessaire aux champs, en supprimant les données dont vous n'avez pas besoin ?
7. Votre politique de conservation/destruction est-elle écrite, communiquée au personnel et opérationnellement implémentée (sauvegardes incluses) ?
8. Connaissez-vous la chronologie de notification du fournisseur, votre escalade interne et le workflow de notification patient/HHS ?
9. La Notice of Privacy Practices est-elle liée depuis le formulaire, et le mécanisme de consentement/autorisation approprié ?
10. Avez-vous parcouru tout le flux vous-même avec une soumission test avant l'ouverture ?

L'essentiel

La collecte de formulaires conforme HIPAA n'est pas une fonctionnalité à cocher. C'est un programme : analyse Privacy Rule de ce que vous collectez et pourquoi, implémentation Security Rule de garanties administratives, physiques et techniques, plan Breach Notification qui sait ce que veut dire « unsecured », BAA avec chaque fournisseur touchant aux PHI, et discipline opérationnelle pour garder tout cela en place tandis que la pratique grandit et la technologie dérive.

Le marketing fournisseur compresse cela en une phrase : « conforme HIPAA ». La phrase est OK si vous la traitez comme le début, pas la fin, de la conversation. Demandez le BAA. Regardez les journaux d'audit. Mappez les garanties sur votre analyse Security Rule. Vérifiez la promesse de notification. Demandez franchement contre quoi protège l'architecture, et contre quoi elle ne protège pas. Les fournisseurs qui répondent clairement à ces questions résisteront mieux à un examen HHS ; ceux qui changent de sujet vous disent quelque chose d'utile.

Le chiffrement zéro-connaissance n'est pas un raccourci HIPAA. C'est cependant la réponse technique la plus forte à plusieurs questions difficiles de la Security Rule, et il retire des catégories entières de risque de l'analyse de notification. Pour les pratiques US qui se soucient vraiment de la confidentialité des PHI — la plupart d'entre elles — il vaut la peine d'être compris, même quand le besoin immédiat est un outil HIPAA mainstream ancré aux USA et adossé à un BAA.