J’ai récemment passé une soirée à demander à Gemini de Google si les outils de chat en ligne destinés aux cliniques avaient besoin d’un Business Associate Agreement. Les réponses étaient formulées avec une assurance totale. Plusieurs étaient pourtant fausses, et pas toutes dans le même sens.
Gemini m’a affirmé qu’un nom associé à une question de santé constituait « toujours » une PHI — une simplification excessive. Il m’a également expliqué qu’un chatbot qui ne stocke aucune donnée était « juridiquement un simple intermédiaire de transmission » — alors que le HHS interprète cette exception de manière beaucoup plus restrictive. À un moment, il a même déclaré que mon propre produit était automatiquement conforme, ce qui est flatteur, mais illustre exactement le type de raccourci trop affirmatif dont parle cet article.
Si les assistants IA que les dirigeants de cliniques consultent sur des questions de conformité peuvent se tromper tout en paraissant parfaitement sûrs d’eux, le sujet mérite qu’on prenne le temps de l’examiner correctement.
Pour les cabinets médicaux, cliniques esthétiques et medical spas aux États-Unis, les questions les plus utiles sont les suivantes :
- Votre établissement est-il réellement une entité couverte par HIPAA ?
- L’outil crée-t-il, reçoit-il, conserve-t-il ou transmet-il des informations de santé protégées (PHI) pour votre compte ?
- Que se passe-t-il lorsqu’un visiteur saisit volontairement des informations personnelles ou médicales dans le chat ?
- Le prestataire conserve-t-il ces informations ?
- Les éléments permettant d’identifier la personne sont-ils supprimés avant que le message ne soit transmis aux systèmes d’IA en aval ?
- Quels autres prestataires technologiques interviennent dans le traitement des données ?
- Si le prestataire agit en tant que business associate, est-il prêt à signer un Business Associate Agreement (BAA) ?
La réponse dépend du parcours réel des données — pas d’un badge affiché dans le pied de page d’un site.
Première chose à comprendre : tous les medical spas ne sont pas automatiquement soumis à HIPAA
HIPAA ne s’applique pas à toutes les entreprises proposant des soins ou des prestations à caractère médical ou esthétique.
Les règles HIPAA s’appliquent aux entités couvertes et à leurs business associates. Un professionnel de santé devient généralement une entité couverte par HIPAA lorsqu’il effectue électroniquement certaines transactions de santé normalisées, notamment certaines opérations liées à la facturation et au paiement. Le HHS précise lui-même qu’un prestataire de soins n’est une entité couverte que s’il remplit les critères applicables.
Cette distinction est particulièrement importante en médecine esthétique, où certains établissements fonctionnent principalement, voire exclusivement, sur un modèle de paiement direct par le patient.
Un medical spa ne devrait donc pas partir automatiquement de l’une de ces deux affirmations :
« Nous proposons des actes médicaux, donc HIPAA s’applique forcément à tout ce que nous faisons. »
ou :
« Nos patients paient directement, donc HIPAA ne nous concerne certainement pas. »
L’établissement doit d’abord déterminer précisément son propre statut.
Et ne pas relever de HIPAA ne signifie pas que les données de santé ne sont soumises à aucune réglementation. D’autres règles fédérales ou étatiques relatives à la vie privée peuvent s’appliquer selon l’activité, les données traitées et la juridiction concernée.
Qu’est-ce qu’une PHI ?
Dans le cadre de la HIPAA Privacy Rule, une protected health information, ou PHI, est une information de santé permettant d’identifier une personne, détenue ou transmise par une entité couverte ou par l’un de ses business associates.
L’information doit concerner l’état de santé passé, présent ou futur d’une personne, les soins qui lui sont fournis ou le paiement de ces soins, tout en permettant de l’identifier directement ou raisonnablement.
Ici, le contexte fait toute la différence. Un message comme :
« Proposez-vous du Botox ? »
n’est pas automatiquement une PHI simplement parce que le Botox est un traitement médical.
En revanche, un message comme :
« Je m’appelle Sarah Jones. J’ai de la rosacée et je prends de l’isotrétinoïne. Puis-je faire ce traitement ? »
crée une situation très différente lorsqu’il arrive dans l’environnement d’une clinique soumise à HIPAA, car il associe des informations permettant d’identifier une personne à des informations concernant sa santé.
L’affirmation courante selon laquelle « PII + question de santé = toujours PHI » reste donc trop simpliste. La qualification de PHI dépend notamment de la personne ou de l’organisation qui détient ou reçoit les informations et du contexte réglementaire dans lequel elles sont traitées.
Mais pour une clinique couverte par HIPAA, toute conversation de santé associée à une personne identifiable mérite une attention particulière.
« Ce n’est qu’un prospect, pas encore un patient » n’est pas une règle sûre
Une autre idée reçue consiste à penser que HIPAA ne commence à s’appliquer qu’au moment où une personne devient officiellement patiente.
Ce n’est pas le bon critère.
La définition HIPAA des informations de santé permettant d’identifier une personne couvre également les informations relatives à la fourniture passée, présente ou future de soins.
L’analyse réglementaire ne dépend donc pas simplement du fait que la personne possède déjà ou non un dossier patient.
Un visiteur qui pose une question sur un traitement tout en révélant son identité peut soulever des questions liées à HIPAA pour une clinique couverte, même s’il se trouve encore au stade de la demande d’information.
Le qualifier de « lead » ou de « prospect » ne change pas la nature des données traitées.
Quand un prestataire logiciel a-t-il besoin d’un BAA ?
Un Business Associate Agreement est généralement nécessaire lorsqu’un prestataire agit en tant que business associate d’une entité couverte par HIPAA.
Le HHS définit notamment comme business associate une organisation qui crée, reçoit, conserve ou transmet des PHI pour le compte d’une entité couverte dans le cadre de certaines fonctions ou prestations.
Les termes importants sont donc « crée, reçoit, conserve ou transmet » — pas « stocke de manière permanente ».
Ce qui rend trompeuse cette affirmation fréquemment utilisée par certains prestataires :
« Notre chatbot ne sauvegarde pas les conversations, donc nous n’avons pas besoin de BAA. »
Ne pas conserver les conversations constitue une protection importante pour la vie privée. Cela réduit la quantité d’informations sensibles susceptibles d’être exposées ultérieurement et s’inscrit dans une bonne logique de minimisation des données.
Mais le stockage permanent n’est qu’une partie du sujet sous HIPAA.
« Nous ne stockons rien » ne signifie pas « nous ne traitons jamais rien »
Prenons l’exemple d’un visiteur qui écrit :
« Je m’appelle Jane Smith. J’ai subi une chirurgie mammaire l’année dernière et je voudrais savoir si je peux subir une nouvelle intervention. »
Un chatbot peut traiter ce message sans créer de dossier permanent de la conversation.
Les bonnes questions sont alors :
- Où le message brut arrive-t-il en premier ?
- Est-il temporairement traité par le fournisseur du chatbot ?
- Les informations permettant d’identifier la personne sont-elles détectées et supprimées ?
- Le message non anonymisé apparaît-il dans des logs applicatifs ou d’infrastructure ?
- Le message complet est-il transmis au modèle d’IA ?
- Est-il envoyé à d’autres sous-traitants ou prestataires ?
- Une version identifiable du message est-elle conservée après le traitement de la requête ?
Un système conçu pour ne pas conserver les conversations présente un risque très différent d’un système qui sauvegarde indéfiniment chaque échange et crée des profils de prospects identifiables.
L’anonymisation est utile — mais à quel moment intervient-elle ?
Prenons deux architectures possibles.
Architecture A
Un visiteur envoie une question de santé contenant des informations permettant de l’identifier.
Le message complet est stocké dans un historique de conversation ou dans une fiche prospect.
La clinique peut ensuite se connecter à son tableau de bord et consulter :
- le nom du visiteur ;
- ses coordonnées ;
- son problème ou sa préoccupation de santé ;
- le traitement qui l’intéresse ;
- l’intégralité de l’historique de la conversation.
Les informations peuvent également être envoyées à un fournisseur d’IA pour traitement.
Architecture B
L’assistant ne demande ni nom, ni adresse e-mail, ni numéro de téléphone avant de répondre aux questions.
Si un visiteur fournit volontairement des informations permettant de l’identifier, une couche de détection des PII supprime ces éléments avant que le message ne soit transmis aux systèmes d’IA en aval.
Les conversations complètes ne sont pas conservées.
Le contenu brut des conversations n’est pas enregistré dans les logs applicatifs de production.
La clinique n’a accès ni à des transcriptions identifiables ni à des fiches prospects issues du chat.
Le tableau de bord contient uniquement des informations anonymes et agrégées, par exemple :
- les traitements faisant l’objet de questions ;
- les préoccupations mentionnées ;
- les traitements demandés mais non proposés par la clinique ;
- le nombre de fois où chaque sujet a été mentionné.
Dans le second modèle, le système est conçu autour de la minimisation des données : l’identité du visiteur n’est ni nécessaire à la conversation ni conservée comme un actif commercial.
L’expression « chatbot anonyme » ne règle pas automatiquement toutes les questions liées à HIPAA. Mais cette architecture réduit considérablement la quantité d’informations identifiables exposées, traitées et conservées dès le départ.
Ce qui se passe avant l’arrivée du message dans le modèle d’IA est essentiel
Pour un système d’IA, l’une des questions architecturales les plus importantes est de savoir si les informations permettant d’identifier la personne atteignent le modèle de langage lui-même.
Une architecture respectueuse de la vie privée peut intégrer une couche dédiée à la détection et à la suppression des PII avant tout traitement par l’IA en aval.
Par exemple :
« Je m’appelle Sarah et j’ai de la rosacée. Puis-je faire un traitement laser ? »
peut devenir :
« Je m’appelle [nom masqué pour protéger la vie privée] et j’ai de la rosacée. Puis-je faire un traitement laser ? »
avant que le modèle d’IA ne traite la question.
C’est très différent d’un système qui envoie d’abord l’intégralité du message identifiable au modèle avant de tenter de l’anonymiser.
Les cliniques qui évaluent un fournisseur d’IA devraient donc poser cette question :
À quel moment précis du flux de traitement l’anonymisation intervient-elle ?
Et également :
Le message non anonymisé peut-il apparaître dans des logs de production ou dans un historique de conversation conservé ?
Une architecture de protection des données est d’autant plus robuste que le contenu brut des conversations n’est pas conservé inutilement.
Les logs de développement et les systèmes de production ne sont pas la même chose
Pendant le développement d’un logiciel, les équipes techniques peuvent temporairement activer des logs de diagnostic détaillés afin de vérifier le fonctionnement des systèmes de sécurité, d’anonymisation ou de routage.
Ces logs ne devraient pas automatiquement devenir une composante de l’architecture de production.
Dans un assistant destiné au secteur médical et conçu autour de la protection des données, le système de production devrait éviter que les conversations brutes des visiteurs soient inutilement enregistrées dans des logs applicatifs, des consoles de débogage ou des outils de monitoring.
Une fois les tests terminés, les logs détaillés contenant le contenu des conversations devraient être désactivés ou remplacés par une télémétrie opérationnelle ne permettant pas d’identifier les utilisateurs.
L’objectif est simple :
Ne créez pas une base de données de conversations sensibles dont le produit n’a pas réellement besoin.
Le chiffrement ne suffit pas à rendre un produit « HIPAA compliant »
Le chiffrement est important.
Les contrôles d’accès, les politiques de sécurité, la gestion des risques et l’infrastructure le sont également.
Mais aucun de ces éléments ne constitue une certification officielle de conformité HIPAA.
Le HHS et l’Office for Civil Rights indiquent explicitement qu’ils ne certifient pas les produits comme étant « HIPAA compliant ».
Un prestataire qui affirme :
« Nous utilisons le chiffrement SSL, donc nous sommes HIPAA compliant. »
vous donne donc une réponse incomplète.
De la même manière, la signature d’un BAA ne rend pas automatiquement conforme n’importe quelle utilisation d’un produit.
Le BAA crée des obligations contractuelles entre les parties concernées. L’architecture du système, sa configuration, le parcours des données et l’utilisation effective des PHI restent déterminants.
Signer un BAA ne signifie pas qu’un fournisseur stocke nécessairement des PHI
Il existe également une idée reçue inverse.
Certaines personnes supposent :
« Si un fournisseur logiciel accepte de signer un BAA, cela signifie forcément qu’il stocke des dossiers patients. »
C’est également faux.
Un prestataire peut concevoir son système pour minimiser les données identifiables, ne pas conserver les conversations et supprimer les identifiants personnels avant tout traitement ultérieur, tout en acceptant de signer un BAA avec les clients couverts par HIPAA lorsque la relation juridique l’exige.
L’existence d’un BAA renseigne sur la relation contractuelle entre les parties.
Elle ne décrit pas, à elle seule, l’architecture de conservation des données du fournisseur.
Un prestataire conçu autour du respect de la vie privée peut donc faire les deux :
Minimiser techniquement l’exposition aux PHI.
et
Fournir les garanties contractuelles appropriées lorsqu’une relation de business associate existe.
Ces deux approches sont complémentaires.
Que devrait réellement signifier « HIPAA compliant » lorsqu’un logiciel l’affiche sur son site ?
Les cliniques doivent devenir des acheteurs un peu plus exigeants.
Prenons Workee comme exemple concret.
Workee commercialise directement son logiciel auprès des medical spas, des cabinets dentaires, des centres de bien-être et des cliniques spécialisées dans la perte de poids. Son site affiche publiquement les mentions « HIPAA Compliant », « PCI Compliant » et « SSL Encryption ». Le produit met également en avant des fonctions de réservation, de gestion des clients, d’automatisation, de suivi des prospects ainsi que la collecte d’adresses e-mail et de numéros de téléphone.
Une clinique qui voit cette mention peut raisonnablement penser que la question HIPAA a déjà été réglée.
Mais si vous êtes une entité couverte par HIPAA et que la plateforme crée, reçoit, conserve ou transmet des PHI pour votre compte, la question suivante devrait être immédiate :
Où est le BAA ?
Plus précisément :
« Acceptez-vous de signer un Business Associate Agreement avec notre clinique, et dans le cadre de quelle offre ou de quel contrat ? »
En consultant le site public de Workee pour préparer cet article, je n’ai trouvé ni BAA accessible publiquement ni explication claire du processus permettant d’en signer un.
Cela ne signifie pas que Workee n’en fournit pas un sur demande.
Et cela ne prouve pas non plus que Workee n’est pas conforme.
Cela signifie simplement que la mention « HIPAA Compliant » ne fournit pas, à elle seule, suffisamment d’informations à une clinique couverte par HIPAA qui doit choisir un prestataire.
Si un fournisseur demande aux établissements de santé de se fier à une affirmation aussi visible concernant HIPAA, il devrait être capable d’expliquer clairement ce qui se passe lorsqu’une entité couverte a besoin d’un BAA, quels services sont concernés et quelles garanties s’appliquent aux PHI traitées par la plateforme.
La réponse peut être parfaitement satisfaisante.
Mais la clinique doit tout de même poser la question.
À quoi ressemble une meilleure transparence ?
Comparons maintenant avec Jane, une plateforme de gestion de cabinet conçue pour héberger de véritables données patients.
La question du BAA devient incontournable lorsqu’un logiciel gère des fonctions comme les dossiers patients, la planification des rendez-vous et les workflows cliniques.
Jane aborde la question directement — non pas dans un article de blog, mais dans ses Conditions d'utilisation juridiquement contraignantes, qui stipulent que si un abonné est soumis à la loi HIPAA, Jane conclura, sur demande, son Business Associate Agreement standard avec cet abonné. Pas besoin de deviner à partir d'un badge en pied de page : l'engagement contractuel est inscrit dans les conditions que chaque client accepte.
Cela ne signifie pas que la présence d’un BAA rend automatiquement conforme chaque configuration possible du produit.
Cela signifie que la question contractuelle est traitée directement.
Et c’est un standard utile pour les cliniques qui évaluent un logiciel destiné au secteur médical.
Un fournisseur qui traite des données patients identifiables ne devrait pas vous obliger à reconstituer sa position vis-à-vis de HIPAA à partir d’un badge dans le pied de page, d’un certificat SSL ou d’un texte marketing.
Demandez ce que le système fait réellement avec les PHI.
Demandez quels autres prestataires les traitent.
Et lorsqu’un BAA est nécessaire, posez la question du contrat avant de transmettre de véritables informations patients au système.
La réponse vous en dira bien plus qu’un badge.
Et si le chat du site est anonyme ?
Un assistant d’information patient fonctionnant de manière anonyme peut avoir une empreinte beaucoup plus réduite en matière de vie privée qu’un chatbot classique conçu pour capturer des prospects.
Un tel système peut par exemple :
- répondre à des questions générales sur les traitements ;
- fournir des informations pratiques sur la clinique ;
- ne pas exiger de nom, d’adresse e-mail ou de numéro de téléphone ;
- ne pas créer de profils de prospects identifiables ;
- ne pas donner à la clinique accès aux conversations complètes ;
- ne pas conserver les conversations de manière permanente ;
- supprimer les identifiants personnels saisis volontairement par les visiteurs ;
- empêcher les messages non anonymisés d’atteindre les modèles d’IA en aval ;
- éviter d’enregistrer le contenu brut des conversations dans les logs applicatifs de production ;
- fournir uniquement des statistiques agrégées, comme les traitements ou préoccupations les plus fréquemment mentionnés ;
- orienter les visiteurs prêts à prendre rendez-vous vers le système de réservation déjà utilisé par la clinique.
Le principe est simple :
Ne collectez pas d’informations permettant d’identifier une personne si vous n’en avez pas réellement besoin.
Une personne ne devrait pas avoir à donner son nom et son numéro de téléphone simplement pour demander :
« Proposez-vous Sculptra ? »
ou :
« Combien de temps dure l’éviction sociale après un laser CO2 ? »
L’assistant peut d’abord répondre à la question.
Lorsque le visiteur est prêt à s’identifier et à prendre rendez-vous, il peut saisir directement ses informations dans le système de réservation ou de gestion patient de la clinique.
La capture de leads crée un flux de données différent
Comparons maintenant avec un chatbot qui demande immédiatement :
« Quel est votre nom ? »
« Quelle est votre adresse e-mail ? »
« Quel est votre numéro de téléphone ? »
puis :
« Quel traitement ou quel problème médical souhaitez-vous traiter ? »
Le système peut ensuite tout enregistrer dans une fiche prospect.
La clinique peut se connecter plus tard et relire la conversation.
Cela peut être utile commercialement.
Mais pour une clinique couverte par HIPAA, cela crée une situation de conformité très différente, car le logiciel associe volontairement des personnes identifiables à des demandes concernant leur santé.
Si ce fournisseur agit en tant que business associate, la clinique devrait s’attendre à disposer du BAA approprié et des garanties HIPAA correspondantes.
C’est pourquoi les cliniques ne devraient pas évaluer les chatbots médicaux uniquement en se demandant :
« Est-ce qu’il peut générer davantage de leads ? »
Elles devraient aussi poser cette question :
« Quelles informations a-t-il réellement besoin de collecter ? »
Un lien vers un système de réservation externe expose-t-il les données de réservation au chatbot ?
Pas nécessairement.
Il existe une différence importante entre :
- un assistant IA qui collecte lui-même le nom du visiteur, son problème de santé et ses coordonnées ;
- un assistant qui affiche simplement un lien de réservation standard redirigeant le visiteur vers une autre plateforme.
Dans le second cas, le visiteur quitte l’environnement de l’assistant et saisit directement ses informations personnelles dans le système de réservation ou de gestion patient de la clinique.
Le chatbot ne reçoit pas automatiquement les données saisies sur la page de réservation externe simplement parce qu’il a fourni le lien.
La clinique doit évaluer séparément si son fournisseur de réservation ou de gestion patient agit comme business associate et si un BAA est nécessaire.
Séparer ces environnements peut contribuer à éviter la duplication inutile de données patients.
L’exception étroite du « conduit » ne doit pas être invoquée à la légère
Certains prestataires se présentent comme de simples intermédiaires de transmission au motif qu’ils ne conservent pas les données.
Le HHS interprète pourtant cette notion de manière restrictive.
Elle concerne généralement les services dont le rôle se limite essentiellement à transmettre des informations, avec un accès très limité ou transitoire aux PHI.
Un système d’IA qui analyse le sens du message d’un patient, le classe, génère une réponse ou en extrait des informations structurées fait davantage que simplement transporter un message d’un point A à un point B.
Un fournisseur d’IA sophistiqué ne devrait donc pas s’appuyer trop facilement sur l’argument :
« Nous ne sommes qu’un conduit. »
Ce qui compte, c’est ce que le système fait réellement avec le message, pas le terme que le fournisseur préfère utiliser pour se décrire.
Et les sous-traitants ?
Les produits d’IA modernes fonctionnent rarement de manière totalement isolée.
Selon leur architecture, ils peuvent dépendre de :
- fournisseurs d’infrastructure cloud ;
- fournisseurs de modèles d’IA ;
- services de sécurité ;
- systèmes de détection des PII ;
- infrastructures de bases de données ;
- outils de monitoring.
Si des PHI sont impliquées, le fournisseur doit comprendre ses obligations tout au long de cette chaîne de traitement.
L’absence d’une liste publique de sous-traitants ne signifie pas automatiquement qu’un produit n’est pas conforme.
Mais une clinique qui effectue une véritable vérification préalable devrait pouvoir obtenir des informations utiles sur les endroits où les données sensibles sont traitées et sur les tiers susceptibles d’y avoir accès.
Une réponse vague comme :
« Ne vous inquiétez pas, nos serveurs sont sécurisés. »
ne remplace pas une compréhension claire de l’architecture réelle des données.
Cinq questions à poser à tout fournisseur d’IA ou de chatbot
Au lieu de demander uniquement :
« Êtes-vous HIPAA compliant ? »
demandez :
1. Votre chatbot exige-t-il des informations personnelles avant de répondre aux questions ?
Un assistant respectueux de la vie privée ne devrait pas avoir besoin de connaître l’identité d’un visiteur pour répondre à des questions ordinaires sur un traitement ou sur le fonctionnement de la clinique.
2. Que se passe-t-il si un visiteur saisit volontairement son nom ou ses coordonnées ?
Demandez si le système détecte et supprime les informations permettant de l’identifier, et à quel moment précis du flux de traitement cette suppression intervient.
3. Conservez-vous les conversations complètes ou créez-vous des profils de prospects identifiables ?
Il existe une différence majeure entre des statistiques anonymes agrégées et une base de données consultable contenant des conversations de patients.
4. Les conversations brutes peuvent-elles apparaître dans les logs de production ?
Un système peut affirmer qu’il ne conserve aucun « historique de chat » tout en enregistrant le contenu brut dans des logs applicatifs ou des outils de monitoring.
5. Si vous agissez comme notre business associate, acceptez-vous de signer un BAA ?
Pour une clinique couverte par HIPAA, cette question devrait recevoir une réponse claire.
La vraie leçon : commencez par suivre le parcours des données
Il n’existe aucune règle universelle disant :
Chatbot IA = BAA obligatoire.
Il n’existe pas non plus de règle universelle disant :
Chatbot anonyme = aucun BAA nécessaire.
Et cette affirmation ne suffit pas :
Pas de stockage permanent des conversations = HIPAA ne s’applique pas.
La bonne analyse commence par quatre questions.
Qui est la clinique ?
Est-elle une entité couverte par HIPAA ?
Quelles informations entrent dans le système ?
Permettent-elles d’identifier une personne et révèlent-elles des informations sur sa santé ou ses soins ?
Qui reçoit ou traite ces informations ?
Le fournisseur du chatbot ? Un service d’anonymisation ? Un fournisseur cloud ? Un modèle d’IA ?
Que deviennent ces informations ?
Les éléments identifiants sont-ils supprimés ? Le message brut est-il enregistré ? La conversation est-elle conservée ? La clinique reçoit-elle une transcription permettant d’identifier la personne ?
Ces questions vous en apprendront bien davantage qu’un logo « HIPAA Compliant ».
Une architecture conçue autour de la protection de la vie privée peut réduire considérablement les expositions inutiles.
Un assistant qui n’oblige pas les visiteurs à s’identifier avant de poser une question simple, ne crée pas inutilement des profils patients, ne conserve pas les conversations, supprime les identifiants personnels avant le traitement par l’IA et laisse les données de réservation dans le système de réservation ou de gestion patient approprié de la clinique repose sur un principe solide :
Collecter moins. Partager moins. Conserver moins.
Pour les cliniques, cela signifie moins de copies inutiles d’informations sensibles.
Pour les patients, cela signifie pouvoir poser une question simple ou personnelle sans devoir immédiatement révéler son identité.
Et pour les éditeurs de logiciels, cela signifie intégrer la protection de la vie privée dans l’architecture elle-même plutôt que de considérer un BAA ou un badge « HIPAA Compliant » comme l’ensemble de leur stratégie de conformité.
Pour les cliniques américaines, le parcours des données raconte toute l’histoire de la conformité.
Nat Guribashvili
Founder, iGlowly
LinkedIn
Cet article fournit des informations générales et ne constitue pas un conseil juridique. L’applicabilité de HIPAA dépend du statut de la clinique, des services proposés, de l’architecture technologique et des flux de données concernés. Les cliniques devraient obtenir l’avis d’un professionnel juridique ou d’un spécialiste de la conformité qualifié pour leur situation particulière.