Paiement conforme HIPAA : ce qui est exempté et ce qui ne l'est pas
HIPAA exempte la transaction par carte, mais régit encore ce qui circule autour. Les champs d'une page de paiement de télésanté passés en revue un à un, avec les questions à poser à tout processeur.
- Par le desk d'underwriting d'OpenGate
- Mis à jour
- 16 min de lecture
Le paiement conforme à HIPAA consiste à faire payer un patient sans divulguer plus de données de santé que nécessaire. Sa section 1179 exempte les opérations de paiement d’un établissement financier, comme l’autorisation, la compensation et le règlement d’un paiement de soins par carte, et le HHS américain n’exige pour elles aucun contrat de business associate. L’exemption s’arrête au traitement des fonds. Le risque entoure la transaction : libellés, factures, champs de commande, reçus. Ce guide examine les deux côtés en télésanté.
Dans ce guide
Ce que la loi HIPAA exempte : la transaction de paiement elle-même
HIPAA, la loi fédérale américaine sur les données de santé, ne s’applique pas à un établissement financier, ni à une société qui agit pour son compte, dans la mesure où leur activité consiste à autoriser, traiter, compenser, régler, facturer, transférer, rapprocher ou recouvrer un paiement de soins de santé. C’est ce que prévoit la section 1179 de la loi (42 U.S.C. 1320d-8), qui couvre les paiements par carte de crédit, de débit ou autre carte de paiement, par chèque ou par virement électronique de fonds. La même section couvre ce qui suit un paiement : les litiges et réclamations des clients, les audits et les réponses aux injonctions de produire des documents.
Le HHS, le ministère américain de la Santé, applique cette section dans ses lignes directrices sur les business associates, révisées pour la dernière fois en juillet 2026. Un business associate est un tiers qui traite des informations de santé protégées pour le compte d’une entité soumise à HIPAA, ici le prestataire de soins, et la loi impose de signer avec lui un contrat, le business associate agreement (BAA). Ce contrat n’est pas requis lorsqu’un établissement financier traite des transactions effectuées par des consommateurs par carte de débit, de crédit ou autre carte de paiement, compense des chèques ou traite des virements électroniques de fonds. Le HHS le justifie ainsi : l’établissement rend ses services financiers habituels à ses clients et n’exerce aucune fonction pour le compte du prestataire de soins. L’Omnibus Rule de 2013 dit la même chose : les règles HIPAA, dispositions sur les business associates comprises, ne s’appliquent pas aux banques et aux établissements financiers pour les activités de traitement des paiements énumérées à la section 1179.
Pour un marchand de télésanté, la conséquence est directe : le paiement par carte lui-même n’appelle pas de contrat de business associate avec la banque qui le traite. C’est à votre conseil juridique de dire si une autre société de paiement de la chaîne, une passerelle par exemple, agit pour le compte d’un établissement financier dans votre configuration. L’exemption laisse aussi intactes vos propres obligations de prestataire de soins : ce que vous transmettez avec un paiement reste régi par la Privacy Rule, la règle de HIPAA sur la confidentialité.
Où s’arrête l’exemption et quand un processeur devient business associate
L’exemption couvre le mouvement des fonds et s’arrête là où une société de paiement commence à assurer votre travail administratif. Le HHS l’a dit deux fois. Dans le préambule de la Privacy Rule, il a indiqué que les établissements financiers sont des business associates lorsqu’ils reçoivent des informations de santé protégées pour des activités autres que le traitement des fonds, en citant pour exemple la facturation de back-office et la gestion des créances clients. En 2013, il a répété qu’une banque peut être un business associate lorsqu’elle exerce pour un prestataire de soins des fonctions qui vont au-delà du traitement des paiements.
| Activité | Dans l’exemption des paiements ? | Ce que cela implique pour vous |
|---|---|---|
| Autoriser, compenser et régler un paiement par carte | Oui, quand un établissement financier ou une société qui agit pour son compte s’en charge | Le HHS n’exige aucun contrat de business associate pour cette activité |
| Traiter un chargeback (rétrofacturation) ou une réclamation du porteur sur ce paiement | Oui, la section 1179 cite les litiges des clients | N’envoyez que ce que le litige exige |
| Préparer des relevés détaillés pour les patients ou assurer votre facturation de back-office | Non, le HHS cite ce travail comme celui d’un business associate | Un contrat est requis dès que des informations de patients sont en jeu |
| Gérer vos créances clients ou votre recouvrement | Non | Même règle |
| Stocker des notes de consultation, des réponses au questionnaire médical ou des ordonnances dans un outil de paiement | Non | Laissez-les en dehors, ou choisissez un prestataire qui signe un contrat |
Le HHS définit le business associate par sa fonction : une société qui crée, reçoit, conserve ou transmet des informations de santé protégées pour votre compte. Le nom d’un produit ne change pas la réponse. Une même société peut être exemptée pour son traitement des cartes et être business associate pour son module de facturation.
Ce qu’un paiement conforme à HIPAA laisse hors des champs de paiement
Seul ce dont le paiement a besoin doit l’accompagner. La norme du minimum nécessaire (minimum necessary) de HIPAA s’applique aux informations transmises pour un paiement, et le HHS a décrit ce qu’elle signifie pour une transaction de paiement lorsqu’il a rédigé la Privacy Rule. Dans le préambule de la règle finale, il a indiqué que les informations généralement nécessaires sont le nom et l’adresse de la personne, le nom et l’adresse du payeur ou du prestataire, le montant facturé, la date de la prestation, la date d’expiration du moyen de paiement, la signature et les numéros d’identification et de compte pertinents. Il a donné raison aux participants à la consultation publique pour qui l’envoi aux établissements financiers d’informations de diagnostic et du détail des traitements peut être incompatible avec l’exigence du minimum nécessaire.
Le HHS a aussi concédé un point que les marchands doivent entendre : même ces informations minimales peuvent révéler une pathologie, puisqu’un paiement à un prestataire de soins montre que des soins ont été dispensés. Une marque de télésanté construite autour d’une seule pathologie rend le problème plus aigu. Si le nom de l’entreprise est celui du traitement, la ligne du relevé bancaire est une divulgation.
Les données de santé s’infiltrent dans un flux de paiement à six endroits. Le tableau indique l’erreur type à chacun d’eux et ce qu’il faut envoyer à la place.
| Où | L’erreur type | Ce qu’il faut envoyer |
|---|---|---|
| Libellé de relevé (descriptor) | Un nom de médicament, de pathologie ou de programme sur le relevé bancaire | Une raison sociale ou un nom de marque neutre, celui que le patient a vu sur la page de paiement |
| Lignes d’article et noms de formules | Le médicament et son dosage utilisés comme nom de produit | Un code interne de formule ou de commande |
| Description de commande, métadonnées, champs personnalisés | Réponses au questionnaire médical, codes de diagnostic ou notes du prescripteur copiés depuis le système clinique | Un identifiant de commande que seul votre système sait relier au patient |
| Factures et liens de paiement | Une mention qui nomme le traitement | Montant, date et référence |
| Reçus par e-mail ou SMS | Le traitement écrit en toutes lettres dans un message qui s’affiche sur l’écran verrouillé | La même formulation neutre que le libellé |
| Preuves de litige | Extraits du dossier médical ou résultats d’analyses joints au dossier de représentation | Preuve d’achat, consentement, livraison et historique des échanges avec le patient |
Les paiements par téléphone présentent le même risque. Le personnel qui saisit une carte dans un terminal de paiement virtuel (TPE virtuel) a tendance à taper dans le champ de notes ce qu’il entend : donnez-lui une consigne écrite pour ce champ.
Un exemple concret
Prenons un programme de perte de poids fictif qui facture un deuxième mois de médicament. Les noms sont inventés.
- La version qui laisse fuir les données envoie le libellé EXEMPLE SEMAGLUTIDE RX, une ligne d’article intitulée « sémaglutide en préparation magistrale, renouvellement mois 2 » et un champ de métadonnées qui contient le poids de départ du patient.
- La version propre envoie le libellé EXEMPLE GROUPE SANTE, une ligne d’article intitulée « formule M2 » et la référence de commande 48213.
Les deux versions transportent les mêmes données de carte et aboutissent au règlement du même montant. La seconde garde le diagnostic dans le système clinique, où vos mesures de protection HIPAA s’appliquent déjà, et elle n’apprend rien à un employé de banque, à un proche qui lit un relevé, ni à quiconque récupère un journal dérobé lors d’une fuite de données.
Stripe est-il conforme à HIPAA, et que vaut ce label ?
Aucun processeur n’est conforme à HIPAA au sens où un système est validé PCI, car HIPAA ne prévoit aucune certification officielle. Le HHS indique qu’il n’approuve ni ne reconnaît les certifications privées de conformité à la Security Rule, la règle de HIPAA sur la sécurité des données. La « conformité HIPAA » (HIPAA compliance) qu’un prestataire peut réellement offrir tient en deux engagements : signer un contrat de business associate pour les services qui en exigent un, et concevoir ces services conformément à la Security Rule.
Pour Stripe en particulier, nous rapportons ce que dit son propre contrat, et rien au-delà. Le Contrat de services Stripe (Stripe Services Agreement), modifié pour la dernière fois le 28 septembre 2026, mentionne les informations de santé protégées dans une seule clause. L’utilisateur ne doit pas les transmettre à Stripe parmi les données de tiers, c’est-à-dire les données issues de ses autres prestataires auxquelles Stripe se voit donner accès, et il est responsable de toute divulgation de ce type. Le texte que nous avons lu n’emploie pas le mot HIPAA. C’est à Stripe de dire s’il signe un contrat de business associate pour un produit donné : posez-lui la question par écrit si votre intégration exige plus que le traitement des cartes.
La politique d’utilisation acceptable de Shopify aborde la question du côté de la plateforme. En octobre 2026, elle cite le téléversement d’informations de santé protégées soumises à HIPAA parmi les activités que la plateforme ne prend pas en charge.
Avant même HIPAA, un second obstacle arrête les plateformes qui prescrivent. Stripe et PayPal soumettent tous deux la télémédecine et les produits sur ordonnance à leur accord, et la position d’un processeur sur les données de santé ne compte plus si sa politique d’utilisation acceptable exclut votre modèle. Le déroulement de cet examen pour chaque modèle de télésanté est détaillé dans le guide du paiement en télémédecine.
PCI DSS et HIPAA couvrent des données différentes
PCI DSS protège les données des porteurs de carte et HIPAA protège les informations de santé : être en règle avec l’une ne dit rien de l’autre. PCI DSS, la norme de sécurité du secteur des cartes, encadre le numéro de carte, la date d’expiration et les systèmes qui les manipulent. Une passerelle qui tokenise les cartes et fonctionne sur une infrastructure conforme PCI DSS niveau 1 a réglé le volet carte.
C’est le périmètre que publie OpenGate. Notre page des fonctionnalités indique une infrastructure PCI DSS niveau 1, la tokenisation, une page de paiement hébergée et le paiement par lien. Elle ne mentionne aucune attestation HIPAA, et nous ne présentons pas la passerelle comme un service HIPAA. Traitez-la, ainsi que toute passerelle qui en dit autant, comme un système réservé au paiement : les données de carte y entrent, les données cliniques restent dans votre propre plateforme. Si votre processus exige qu’un prestataire de paiement conserve des informations de patients, soulevez la question avant l’intégration, car la réponse honnête peut être que ce processus doit changer.
Êtes-vous vraiment une entité couverte par HIPAA ?
Certaines sociétés de télésanté échappent à HIPAA, ce qui change les règles applicables sans supprimer le devoir de diligence. Le HHS ne considère un prestataire de soins comme une entité couverte (covered entity) que s’il transmet des informations par voie électronique dans le cadre d’une transaction normalisée, la demande de remboursement adressée à un assureur étant la plus courante. Un programme payé directement par les patients, qui ne facture jamais d’assureur santé, peut donc se trouver hors de HIPAA et relever à la place de la Federal Trade Commission (FTC) et des lois des États américains sur la protection de la vie privée. Faites trancher par un conseil juridique le régime qui s’applique, et vérifiez auprès de lui les règles du pays où vous êtes établi et de ceux où vous vendez. La cartographie des champs ci-dessus mérite d’être suivie dans tous les cas, et les acquéreurs demanderont à voir votre politique de confidentialité quelle que soit la réponse.
Les questions à poser à tout processeur avant de signer
Demandez au processeur ce qu’il fait des données au-delà de la carte, et demandez-le par écrit. Huit questions distinguent une relation limitée au paiement d’une relation qui exige un contrat.
- Lesquels de vos services vont au-delà de l’autorisation, de la compensation et du règlement des paiements ?
- Pour ces services, signez-vous un contrat de business associate ? Sinon, de quelles fonctionnalités devons-nous tenir les informations de patients à l’écart ?
- Que conservez-vous du contenu des champs de description, des métadonnées et des champs personnalisés, pendant combien de temps, et qui peut le consulter ?
- Qu’affichera le libellé de relevé, et pouvons-nous le définir par gamme de produits ?
- Qu’est-ce qui apparaît par défaut sur vos reçus, vos pages hébergées et vos liens de paiement ?
- En cas de litige, que transmettez-vous à la banque émettrice, et pouvons-nous le relire avant l’envoi ?
- Quels sous-traitants reçoivent les données de transaction ?
- Acceptez-vous, sur le principe, la télésanté avec prescription, et attendez-vous une certification comme LegitScript ?
La dernière question fait gagner le plus de temps. Un processeur qui exclut votre modèle rend les sept premières sans objet. La certification elle-même est traitée dans le guide de la certification LegitScript.
Ce qu’il faut préparer avant de faire votre demande
Avant d’envoyer votre dossier, préparez une cartographie des données tenant sur une page : chaque champ que votre page de paiement, vos factures et votre terminal virtuel transmettent au système de paiement, avec un exemple de valeur pour chacun. Ajoutez le libellé de relevé que vous proposez, des captures d’écran de la page de paiement et d’un reçu, votre politique de confidentialité et les documents habituels d’un compte marchand de télésanté : licences, circuit de prescription, historique de traitement et documents sociaux.
Un underwriter qui constate qu’aucune donnée clinique n’atteint les champs de paiement a une question de moins à poser, et les litiges se défendent mieux avec des preuves propres dès le départ. Le volet litiges est traité dans le guide pour réduire le ratio de chargebacks.
Ensuite, envoyez la cartographie des données avec votre demande de compte marchand de télésanté. Un underwriter l’examine avec le reste du dossier et vous répond sous 1 jour ouvré : une offre écrite, la liste des pièces manquantes ou un refus motivé. L’examen est gratuit. Rien dans cet article ne constitue un avis juridique. Faites confirmer par un conseil votre statut au regard de HIPAA et vos obligations avant de vous fonder sur ce qui précède.