Formulaires HIPAA : qui signe un BAA ?

Chaque cabinet de santé qui se met en quête d'un outil de formulaires en ligne finit par tomber sur les deux mêmes questions. La première est « est-ce conforme HIPAA ? » La seconde « signeront-ils un BAA ? » Les pages marketing répondent oui avec assurance aux deux et brouillent au passage le fait qu'il s'agit de deux questions différentes appelant deux types de réponse différents — l'une sur un contrat juridique, l'autre sur une propriété de l'ensemble de votre programme de conformité.

Cette comparaison démêle les deux, puis passe en revue, fournisseur par fournisseur, les outils de formulaires que les cabinets américains présélectionnent réellement — Google Forms, Microsoft Forms, JotForm, Cognito Forms et Formstack — et montre, pour chacun, si un Business Associate Agreement (BAA) est disponible, quel palier de plan il exige, ce qu'est vraiment le modèle de chiffrement, et la question que la plupart des pages de comparaison sautent entièrement : le fournisseur peut-il techniquement lire vos Protected Health Information (PHI) ? Schweizerform figure aussi dans le tableau, et nous sommes honnêtes sur l'endroit exact où il convient et où il ne convient pas.

Ce qu'est vraiment un BAA (et ce qu'il n'est pas)

Un Business Associate Agreement est un contrat. Sous HIPAA, lorsqu'un fournisseur crée, reçoit, conserve ou transmet des PHI pour le compte d'une covered entity, ce fournisseur est un « business associate », et la covered entity doit avoir un BAA avec lui. Le BAA oblige le fournisseur à mettre en œuvre les garanties de la Security Rule, limite la manière dont il peut utiliser et divulguer les PHI, exige qu'il signale les violations et qu'il répercute les mêmes obligations sur ses propres sous-traitants qui touchent des PHI.

Ce qu'un BAA n'est pas : ce n'est pas un certificat, ce n'est pas un contrôle technique, et ce n'est pas ce qui vous rend conforme. Aucun organisme public ne délivre un tampon « conforme HIPAA » à un produit. « Conforme HIPAA » est une propriété de l'ensemble de votre programme — votre analyse Privacy Rule, vos garanties Security Rule, votre plan de notification de violation, et oui, vos BAA — et non une étiquette livrée avec un produit. Un fournisseur peut vous remettre un BAA parfaitement valide et laisser malgré tout votre programme non conforme si le reste des garanties n'est pas en place.

Spécifications required vs addressable en 60 secondes

La Security Rule répartit ses spécifications de mise en œuvre en deux types : « required » et « addressable ». Cette seule distinction est à l'origine de plus de mauvais marketing HIPAA que presque n'importe quoi d'autre, il vaut donc la peine de la clarifier avant qu'un fournisseur ne vous dise ce qu'il doit faire et ne pas faire.

• Required signifie : vous devez le mettre en œuvre. Aucune marge.
• Addressable ne signifie PAS optionnel. Cela signifie : mettre en œuvre la spécification, OU documenter pourquoi elle n'est pas raisonnable dans votre environnement et quelle garantie équivalente vous avez mise en place à la place.
• Le chiffrement — en transit et au repos — est une spécification addressable. Depuis l'Omnibus Rule de 2013 et une longue série d'actions de mise en application du HHS, les régulateurs traitent le chiffrement comme l'attente par défaut et ont sanctionné les entités qui l'ont sauté sans analyse écrite défendable.

Nous détaillons les Privacy, Security et Breach Notification Rules bien plus en profondeur dans notre article compagnon sur la collecte de formulaires conforme HIPAA — cette page suppose les bases acquises et se concentre spécifiquement sur la question BAA-et-chiffrement. Version courte : le chiffrement n'est pas techniquement obligatoire, mais en pratique vous le mettez en œuvre ou vous rédigez une très bonne explication de pourquoi vous ne l'avez pas fait.

Qui signe un BAA — fournisseur par fournisseur

Voici la réalité pratique pour les outils de formulaires que les cabinets américains présélectionnent le plus souvent. Pour chacun, les questions qui comptent sont : un BAA est-il disponible, sur quel plan, quel est le modèle de chiffrement, et qui peut techniquement atteindre les PHI en clair.

Google Forms / Google Workspace

Google propose un BAA qui couvre les services principaux de Google Workspace, y compris Google Forms — mais uniquement pour les comptes Workspace payants, et l'administrateur doit activement examiner et accepter le BAA dans la console d'administration. Le produit grand public gratuit Google Forms (un compte Gmail personnel collectant un questionnaire de santé) n'est couvert par aucun BAA, point final. C'est l'erreur la plus courante et la plus coûteuse de tout ce domaine : un cabinet utilise « Google Forms gratuit », suppose que, parce que Google est une entreprise sérieuse, ce doit être correct, et découvre lors d'un audit que le produit grand public n'a jamais été éligible au BAA.

Modèle de chiffrement : Google chiffre les données en transit (TLS) et au repos sur son infrastructure, et Google détient les clés. Les réponses de formulaire sont lisibles par les systèmes de Google. Qui peut techniquement atteindre les PHI : l'infrastructure de Google et toute partie capable de contraindre Google en vertu du droit américain. La localisation par défaut des données est les États-Unis, configurable sur les paliers entreprise mais avec une latitude de traitement conservée par Google.

Microsoft Forms / Microsoft 365

Microsoft inclut des conditions de BAA pour ses services couverts via ses Product Terms et le Business Associate Agreement HIPAA qui fait partie de sa licence commerciale pour les abonnements Microsoft 365 / Office 365 éligibles. Pour les cabinets déjà standardisés sur Microsoft 365, Microsoft Forms à l'intérieur d'un tenant couvert peut entrer dans ce cadre de BAA — mais, comme toujours, l'éligibilité est liée à la licence et à la configuration du tenant, pas au produit grand public, et vous devez confirmer que le service précis est dans le périmètre.

Modèle de chiffrement : TLS en transit, chiffrement au repos avec des clés détenues par Microsoft (des options de clés gérées par le client existent sur certains services, mais la plateforme du fournisseur peut quand même traiter les données). Qui peut techniquement atteindre les PHI : la plateforme de Microsoft et les parties capables de la contraindre en vertu du droit américain. La localisation des données dépend des paramètres de région du tenant.

JotForm

JotForm propose des comptes HIPAA avec un BAA, disponibles sur ses paliers payants supérieurs (Silver, Gold et Enterprise, avec les fonctionnalités HIPAA débloquées à partir des paliers supérieurs). Lorsque vous activez le mode HIPAA, JotForm applique des contrôles supplémentaires et signera un BAA. C'est une offre réelle et utilisable, et un choix courant pour les cabinets américains qui veulent une étendue de fonctionnalités plus un BAA.

Modèle de chiffrement : TLS en transit et chiffrement au repos, JotForm détenant les clés. Qui peut techniquement atteindre les PHI : les serveurs de JotForm — et donc le personnel de JotForm et toute partie disposant d'un accès au niveau application ou d'une demande légale — peuvent lire les soumissions en clair. Le BAA répartit la responsabilité de cet accès ; il ne supprime pas l'accès. La localisation des données est principalement les États-Unis, avec des options UE sur les plans supérieurs.

Cognito Forms

Cognito Forms est l'outil que beaucoup recherchent spécifiquement en tapant « cognito forms hipaa compliance baa », il mérite donc une réponse soignée et équitable. Cognito Forms propose des fonctionnalités HIPAA et signera un BAA sur ses plans supérieurs (Pro et au-dessus, avec activation HIPAA sur les paliers supérieurs). Il dispose aussi d'un différenciateur véritablement utile que la plupart des constructeurs généralistes n'ont pas : une fonctionnalité « Encrypted Fields », qui vous permet de marquer des champs spécifiques comme chiffrés afin que ces valeurs soient stockées chiffrées au repos plutôt qu'en clair.

C'est une vraie fonctionnalité, nettement meilleure que les outils qui stockent tout en clair. Mais il est important de comprendre précisément ce qu'elle est et ce qu'elle n'est pas. Encrypted Fields est un chiffrement côté serveur, géré par le fournisseur : Cognito détient l'infrastructure de clés, et les serveurs de Cognito voient le texte clair pendant le traitement de la soumission et déchiffrent le champ lorsque vous, le propriétaire du formulaire, consultez la soumission. Ce n'est pas du chiffrement de bout en bout. La réponse honnête à la requête de recherche est donc : oui, Cognito Forms propose des fonctionnalités HIPAA et un BAA sur les plans supérieurs, et ses Encrypted Fields rehaussent la protection au repos — mais Cognito peut toujours techniquement accéder aux PHI, car il détient les clés. Le BAA est ce qui répartit la responsabilité juridique de cet accès.

Formstack

Formstack est une plateforme de workflow d'entreprise axée conformité (formulaires, documents, signature électronique) qui propose un plan conforme HIPAA avec un BAA sur ses paliers supérieurs. Pour les équipes mid-market et entreprise qui veulent des formulaires plus la génération de documents et l'e-sign chez un seul fournisseur avec un BAA, c'est un choix standard et crédible.

Modèle de chiffrement : TLS en transit et chiffrement au repos, Formstack détenant les clés. Qui peut techniquement atteindre les PHI : l'infrastructure de Formstack, son personnel autorisé, les intégrations et toute partie avec une demande légale peuvent atteindre les données en clair. Là encore, le BAA répartit la responsabilité ; il ne change pas le fait que les systèmes du fournisseur peuvent lire les données. La localisation des données est principalement les États-Unis.

Le tableau comparatif

Lisez les deux dernières colonnes ensemble. « BAA disponible » vous dit si un fournisseur accepte la responsabilité juridique des PHI. « Le fournisseur peut-il techniquement lire les PHI ? » vous dit si cette responsabilité est la seule chose entre les données de vos patients et le personnel du fournisseur. Ce sont des axes différents, et la différence est tout l'enjeu de cette page.

Un BAA n'est pas une stratégie de chiffrement

C'est la section vers laquelle pointe réellement le tableau comparatif. Un BAA et le chiffrement de bout en bout (E2EE) réduisent tous deux le risque, mais ils accomplissent des tâches complètement différentes et ne se substituent pas l'un à l'autre.

Un BAA est une répartition juridique de responsabilité. Quand une violation survient, le BAA détermine qui doit notifier qui, qui porte quelles obligations et comment la responsabilité est partagée entre la covered entity et le business associate. C'est un instrument de papier. Il ne fait rien, en soi, pour empêcher la violation ou rendre les données exposées illisibles. Chaque fournisseur établi qui signe un BAA peut techniquement accéder aux PHI — son chiffrement au repos utilise des clés que le fournisseur détient, ce qui signifie que les systèmes, le personnel et les intégrations du fournisseur, ainsi que quiconque peut le contraindre légalement, peuvent en principe atteindre le texte clair. Le BAA dit « nous promettons de gérer cet accès de manière responsable et de vous prévenir si quelque chose tourne mal ».

Le chiffrement de bout en bout est un contrôle architectural. Avec un vrai E2EE à connaissance nulle, les données sont chiffrées sur l'appareil du répondant avant même d'atteindre le fournisseur, et le fournisseur ne détient jamais les clés. Lors d'une violation, ce qu'un attaquant — ou une assignation — obtient est du texte chiffré sans chemin de déchiffrement. La différence, c'est la différence entre « autorisé à détenir des PHI lisibles, et contractuellement tenu de bien les gérer » et « ne peut pas détenir de PHI lisibles du tout ».

Un BAA décide qui est responsable lorsque des PHI lisibles sont exposées. Le chiffrement de bout en bout décide s'il existe seulement des PHI lisibles à exposer. Les meilleurs programmes ne choisissent pas entre les deux — ils comprennent lequel chaque outil leur donne réellement.

Où Schweizerform s'inscrit honnêtement

Il est temps d'être direct sur notre propre produit, car toute la valeur de cette page en dépend. Schweizerform n'offre pas de Business Associate Agreement HIPAA et n'est pas positionné comme un fournisseur HIPAA. Si votre liste d'achat comporte une ligne ferme indiquant « le fournisseur doit signer un BAA », Schweizerform ne satisfait pas cette ligne aujourd'hui, et nous ne prétendrons pas le contraire.

Ce que Schweizerform possède, c'est la propriété architecturale dont traite toute la colonne « le fournisseur peut-il techniquement lire les PHI ? ». Chaque soumission — y compris les pièces jointes — est chiffrée dans le navigateur du répondant avec AES-256-GCM, la clé par soumission étant enveloppée par la clé publique RSA-OAEP-2048 du formulaire. La clé privée du propriétaire est protégée par une Master Key dérivée de son Access Code, qui ne quitte jamais son appareil. Nos serveurs, hébergés exclusivement en Suisse chez Infomaniak, ne stockent que du texte chiffré. Nous ne détenons aucune clé. Nous ne pouvons pas déchiffrer les soumissions — ni pour le support, ni pour l'analytique, ni sous une demande légale suisse. Cela change la conversation sur le risque : il n'y a, de notre côté, aucune PHI lisible sur laquelle un BAA devrait répartir la responsabilité, parce qu'il n'y a aucune PHI lisible de notre côté tout court.

Il y a aussi un second public que cette page ne devrait pas perdre. Pour les organisations de santé et apparentées hors des États-Unis — en Suisse, dans l'UE et l'EEE plus large — HIPAA n'est tout simplement pas le cadre opérant. Les régimes pertinents sont la nLPD suisse et le RGPD (y compris les règles de l'article 9 pour les données de santé de catégorie particulière). C'est le terrain de prédilection de Schweizerform : hébergement suisse, juridiction suisse hors de portée du CLOUD Act américain, aucun sous-traitant américain dans le chemin de données des soumissions, et chiffrement à connaissance nulle sur chaque plan, y compris le palier gratuit. Pour ces acheteurs, la question du BAA est un faux problème, et la question chiffrement-et-souveraineté est celle qui compte.

Un cadre de décision

Suivez ces cinq étapes dans l'ordre et la question du fournisseur se résout généralement d'elle-même.

En résumé

« Est-ce conforme HIPAA ? » et « signeront-ils un BAA ? » sont deux questions, et la réponse honnête grand public est cohérente entre Google Workspace, Microsoft 365, JotForm, Cognito Forms et Formstack : oui, un BAA est disponible au palier payant ou entreprise approprié, et oui, le fournisseur peut toujours techniquement lire vos PHI, car c'est ainsi que fonctionne le chiffrement à clés détenues par le fournisseur. Le BAA est le contrôle qui régit cet accès. Pour les covered entities américaines, ce modèle est bien balisé et souvent exactement le bon — vérifiez seulement qu'il couvre le produit et le plan que vous utilisez réellement.

Le point pour lequel cette page existe est qu'un BAA n'est pas une stratégie de chiffrement. Il répartit la responsabilité des PHI lisibles ; il ne rend pas les PHI illisibles. Le chiffrement de bout en bout à connaissance nulle est l'alternative architecturale — le fournisseur ne peut pas lire les PHI du tout — et c'est une posture véritablement différente, même si, dans le cas de Schweizerform, elle vient sans BAA et n'est pas un package HIPAA américain clé en main. Choisissez la voie qui correspond à vos obligations, vérifiez l'affirmation par écrit, et documentez pourquoi.