By · Last updated 2026-04-02

Retour au blogSanté

Pourquoi les LLM manquent 50 % des PHI cliniques...

Une étude de 2025 a révélé que les LLM manquent plus de 50 % des PHI cliniques dans des documents multilingues.

April 2, 20269 min de lecture
LLM PHI detectionHIPAA de-identificationclinical NLPSafe Harbor methodhealthcare AI compliance

Le problème des 50 % d'omissions

Une étude de 2025 (arXiv:2509.14464) a testé des outils LLM sur des dossiers cliniques. Les résultats étaient mauvais. Ces outils ont manqué plus de 50 % des PHI cliniques dans des documents multilingues. La cause est simple. Les LLM sont conçus pour produire du texte. Ils ne sont pas conçus pour la détection à haute performance que HIPAA exige.

HIPAA Safe Harbor liste 18 types d'identifiants protégés. Noms, dates, numéros de téléphone, numéros de sécurité sociale, MRN, identifiants de plans de santé, identifiants d'appareils et adresses IP. Chacun nécessite sa propre logique de détection.

Les notes cliniques rendent cela plus difficile. Prenons cet exemple : « Pt. John D., DOB 4/12/67, MRN 1234567, admis le 03/15/24, Dr. Smith a prescrit un ECG. » Une seule phrase. Cinq identifiants protégés. La plupart utilisent des abréviations. Un modèle conçu pour la compréhension clinique échoue souvent à la tâche de détection.

Ce que les LLM manquent et pourquoi

Les outils LLM échouent sur les dossiers cliniques de manière prévisible.

Identifiants abrégés : Les notes cliniques utilisent des abréviations. DOB, MRN et Pt. sont des formes courantes. Un modèle orienté vers le sens clinique peut ne pas signaler « Pt. John D. » comme un nom. L'extraction de données sensibles nécessite un objectif différent.

Dates dépendantes du contexte : Toutes les dates ne présentent pas le même risque. « Âge 67 » est un marqueur indirect. « DOB 4/12/67 » est un identifiant directement protégé. « 03/15/24 » comme date d'admission est aussi protégé. La correspondance de motifs seule ne suffit pas.

Formats non américains : Cyberhaven (T4 2025) a constaté que 34,8 % de toutes les entrées ChatGPT contiennent des données sensibles, y compris des PII multilingues. En santé, cela inclut les identifiants de dossiers non américains, les formats de dates régionaux et les types d'identifiants de santé locaux. Les outils formés sur des données américaines les ignorent systématiquement.

Identifiants hospitaliers personnalisés : Les hôpitaux utilisent leurs propres formats MRN, identifiants du personnel et codes de site. Ces données ne figurent pas dans les ensembles d'entraînement NER standard. Un outil sans prise en charge des entités personnalisées ne les trouvera pas.

Le risque des ensembles de données de recherche

Un hôpital construisant un ensemble de données de recherche à partir de 500 000 notes fait face à un vrai problème de conformité. HIPAA exige un standard de « très faible risque » pour les données anonymisées. Un outil manquant la moitié de tous les identifiants protégés ne peut pas atteindre ce seuil.

Les archives de recherche ne sont pas des données propres. Les notes couvrent de nombreux services, périodes et parfois des langues différentes. Un outil fonctionnant sur des données de facturation peut échouer sur des notes narratives. Les données sensibles en texte libre n'ont pas de libellé de champ.

L'approbation IRB impose des exigences supplémentaires. Les établissements doivent montrer la méthode utilisée, les types d'identifiants supprimés et les contrôles effectués. Un outil manquant la moitié de tous les enregistrements ne peut pas satisfaire ces exigences.

Consultez notre aperçu de conformité et nos pratiques de sécurité pour savoir comment anonym.legal soutient les flux de travail HIPAA.

La solution à trois couches

L'étude 2025 a identifié un schéma clair. Les outils avec les taux d'omission les plus bas utilisaient trois couches de détection.

Couche une — regex : Trouve les identifiants structurés. Numéros de sécurité sociale, MRN, numéros de téléphone, identifiants de plans de santé. Fiable sur les formats fixes.

Couche deux — NER : Utilise des modèles transformeurs. Trouve les noms, les dates et les données sensibles dans le texte narratif. Fonctionne là où le regex échoue.

Couche trois — entités personnalisées : Gère les formats propres à chaque site. Modèles MRN propriétaires, identifiants du personnel, codes d'établissement. Aucun modèle standard ne couvre ces éléments.

Les outils ML purs se dégradent sur les formes abrégées et le texte non anglais. Les outils regex purs manquent les données sensibles sans libellé de champ. Aucun seul ne suffit.

Seule la conception à trois couches a atteint des taux d'omission inférieurs à 5 % dans l'étude. C'est le seuil de conformité HIPAA Safe Harbor.

Consultez notre guide sur la dépseudonymisation HIPAA Safe Harbor pour la recherche pour les prochaines étapes.

Sources

Prêt à protéger vos données ?

Commencez à anonymiser les PII avec plus de 285 types d'entités dans 48 langues.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.