+150 XP

Cartographier le paysage des données en biotech et medtech

Un cardiologue prescrit un nouvel anticoagulant. Six mois plus tard, une analyste sécurité veut savoir : les patients sous ce médicament saignent-ils plus que prévu ? Pour répondre, il lui faut au moins quatre jeux de données différents, dont aucun n'a été conçu pour dialoguer avec les autres. Le dossier patient informatisé montre la prescription. La base de claims montre le passage à l'hôpital. Le registre d'événements indésirables montre le saignement déclaré. Le panel génomique explique peut-être pourquoi un patient a mal réagi. Chaque jeu de données détient une part de la vérité, et chacun a des angles morts que les autres ne comblent pas.

C'est la compétence centrale de cette leçon : savoir quel jeu de données répond à quelle question, et où chacun vous ment.

Les six jeux de données de base

1. dossiers patients informatisés (ehr)

Les EHR sont le dossier clinique produit pendant la prise en charge : diagnostics, prescriptions, demandes d'analyses, notes du médecin, constantes vitales. Aux États-Unis, les éditeurs dominants sont Epic et Oracle Health (ex-Cerner). En Europe, le paysage est plus fragmenté entre systèmes nationaux.

Répond bien à : qu'est-il arrivé cliniquement à ce patient ? Qu'a-t-on mesuré, prescrit, diagnostiqué ?

Ne peut pas répondre à : ce qui s'est passé en dehors de ce système de santé. Si un patient consulte dans un hôpital concurrent, cette visite est invisible. Les données EHR sont aussi désordonnées : notes en texte libre, codage incohérent, diagnostics saisis pour la facturation plutôt que pour l'exactitude clinique.

Les diagnostics sont généralement codés en CIM-10 (Classification internationale des maladies, 10e révision, le référentiel de codes diagnostiques de l'OMS). Les actes utilisent souvent la CPT (Current Procedural Terminology) aux États-Unis.

2. Données de claims

Les claims sont les enregistrements de facturation échangés entre les professionnels de santé et les payeurs (assureurs, ou en Europe, systèmes de santé nationaux). Chaque médicament, test et acte remboursé laisse un claim.

Répond bien à : le patient a-t-il retiré son traitement ? Quel a été le parcours de soins complet entre professionnels ? Les claims suivent l'argent, ils captent donc l'activité entre institutions.

Ne peut pas répondre à : les résultats cliniques et les valeurs de laboratoire. Un claim vous dit qu'un test a été facturé, pas son résultat. Il y a aussi un décalage : les claims sont liquidés des semaines à des mois après l'événement.

Aux États-Unis, les Centers for Medicare and Medicaid Services (CMS) publient de vastes jeux de données de claims. Une porte d'entrée gratuite utile : le portail CMS Research Data.

3. Données génomiques

Séquençage de l'ADN, expression génique, données de variants. Les formats incluent FASTQ (lectures brutes), BAM (lectures alignées) et VCF (Variant Call Format, qui liste les endroits où un génome diffère d'une référence).

Répond bien à : pourquoi un patient a-t-il répondu ou non ? Quelle mutation pilote une tumeur ? La génomique sous-tend l'oncologie de précision, par exemple en associant un patient atteint d'un cancer du poumon avec mutation EGFR à une thérapie ciblée.

Ne peut pas répondre à : ce que le patient a réellement vécu cliniquement. Un variant est une probabilité, pas un résultat. Les fichiers génomiques sont aussi énormes (un génome entier représente environ 100 à 200 gigaoctets non compressés) et exigent une gouvernance lourde parce qu'ils sont par nature identifiants.

4. Registres d'événements indésirables

La déclaration de sécurité post-commercialisation. La FDA américaine (Food and Drug Administration) gère FAERS (FDA Adverse Event Reporting System). L'équivalent européen est EudraVigilance, géré par l'EMA (Agence européenne des médicaments). Pour les dispositifs, la FDA gère MAUDE (Manufacturer and User Facility Device Experience).

Répond bien à : quels signaux de sécurité sont déclarés pour un médicament ou un dispositif sur l'ensemble du marché ?

Ne peut pas répondre à : les taux d'incidence réels. Ce sont des systèmes de déclaration spontanée, c'est-à-dire que les signalements sont volontaires et incomplets. Vous ne pouvez pas calculer un taux réel parce que vous connaissez le numérateur (les déclarations) mais pas le dénominateur (le total de patients exposés). La sous-déclaration est massive, et les signalements bondissent après une couverture médiatique. Ne traitez jamais un décompte FAERS brut comme un taux.

FAERS est public et consultable via l'API openFDA.

5. Systèmes de laboratoire (LIMS)

Les Laboratory Information Management Systems suivent les échantillons, les essais et les résultats, en laboratoire clinique comme en recherche. Dans les sociétés de diagnostic et la R&D pharmaceutique, les données LIMS sont la colonne vertébrale de la reproductibilité expérimentale.

Répond bien à : quel était le résultat réellement mesuré, avec ses contrôles qualité associés ? L'essai était-il validé ?

Ne peut pas répondre à : quoi que ce soit sur le patient au-delà de l'échantillon. Le LIMS est centré sur l'échantillon, pas sur le patient.

6. Systèmes de production (MES)

Les Manufacturing Execution Systems et leurs données relèvent des BPF (Bonnes pratiques de fabrication, le standard qualité réglementé pour produire médicaments et dispositifs). Ils enregistrent les dossiers de lot, les conditions environnementales, la calibration des équipements et les déviations.

Répond bien à : ce lot a-t-il été fabriqué correctement ? Le procédé est-il sous contrôle ? Critique pour les biologiques, où le procédé définit largement le produit.

Ne peut pas répondre à : quoi que ce soit de clinique. Mais une déviation de production peut déclencher un rappel qui apparaîtra des mois plus tard dans les données d'événements indésirables : ces mondes se rejoignent donc.

Faire dialoguer les jeux de données : le problème du linkage

Le plus dur est de joindre ces sources. Il existe rarement une clé patient partagée. Le linkage repose sur des identifiants tokenisés (hachages préservant la confidentialité du nom, de la date de naissance et d'autres champs) ou sur des modèles de données standardisés.

Le standard le plus important à connaître est le OMOP CDM (Observational Medical Outcomes Partnership Common Data Model), maintenu par la communauté OHDSI. Il restructure les données EHR et de claims dans un format commun, de sorte que la même analyse tourne d'un hôpital à l'autre et d'un pays à l'autre. En génomique et dans les échanges cliniques, FHIR (Fast Healthcare Interoperability Resources) est le standard d'API dominant.

Qualité des données : les métriques qui comptent

Ici, la qualité des données n'a rien d'abstrait. Une valeur de laboratoire manquante peut invalider un dossier réglementaire. La communauté OHDSI regroupe les contrôles qualité en trois dimensions à mémoriser :

  • Conformance : les données respectent-elles le format attendu ? (Chaque code CIM-10 est-il un code valide ?)
  • Complétude : combien manque-t-il ? (Quel pourcentage de patients a un indice de masse corporelle renseigné ?)
  • Plausibilité : la valeur est-elle crédible ? (Une pression artérielle systolique de 400 est impossible.)

Un exemple chiffré : la complétude

Supposons que vous extrayiez 50 000 patients diabétiques d'un EHR et que vous vouliez utiliser l'HbA1c (un marqueur du contrôle glycémique) comme critère de résultat. Vous constatez que 32 000 patients ont au moins une valeur d'HbA1c enregistrée.

Complétude = 32 000 / 50 000 = 64 %

Cet écart de 36 % n'est pas aléatoire. Les patients dont les valeurs sont enregistrées sont généralement plus malades ou plus impliqués, un biais appelé informed presence. Si vous analysez seulement les 64 %, vos résultats risquent de ne pas être généralisables. La métrique signale le problème ; le jugement le corrige.

Voici le même contrôle exprimé en SQL sur une table de type OMOP :

sql
SELECT
  COUNT(DISTINCT person_id) FILTER (
    WHERE measurement_concept_id = 3004410  -- HbA1c
  )::float
  / COUNT(DISTINCT person_id) AS hba1c_completeness
FROM measurement;

Vérification des acquis

1. Une analyste sécurité doit savoir si des patients ayant quitté un système hospitalier ont effectivement retiré leur traitement et bénéficié d'un suivi chez d'autres professionnels. Quel jeu de données est le plus adapté pour répondre ?

2. Pourquoi la leçon insiste-t-elle sur le fait de savoir « où chaque jeu de données vous ment » plutôt que simplement lequel utiliser ?

3. Un champ de diagnostic d'un EHR indique une pathologie qui ne correspond pas aux notes en texte libre du médecin. Quelle est l'explication conceptuelle la plus probable suggérée par la leçon ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les bonnes réponses concernant les limites des dossiers patients informatisés (EHR) telles que décrites dans la leçon.

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les bonnes réponses qui associent correctement une question de données au jeu de données qui y répond bien.

Sélectionnez toutes les réponses correctes.

Gouvernance : qui a le droit de toucher aux données

Chacun des jeux de données ci-dessus est réglementé, et les règles diffèrent selon la géographie.

États-Unis : HIPAA (Health Insurance Portability and Accountability Act) encadre les informations de santé protégées. Les données peuvent être utilisées plus librement une fois dé-identifiées, ce que HIPAA définit par deux méthodes : Safe Harbor (suppression de 18 identifiants spécifiés) ou Expert Determination (un statisticien certifie un faible risque de ré-identification).

Europe : le RGPD (Règlement général sur la protection des données) traite les données de santé et génétiques comme une catégorie particulière exigeant une base légale solide. Le nouvel espace européen des données de santé (EHDS), adopté en 2024 et déployé jusqu'à la fin des années 2020, crée un cadre de réutilisation des données de santé pour la recherche entre États membres. Attendez-vous à ce qu'il remodèle l'accès en Europe dans les prochaines années.

Pour la medtech en particulier, les dispositifs dans l'UE relèvent du MDR (règlement sur les dispositifs médicaux), qui impose une collecte de données post-commercialisation continue.

La génomique mérite une prudence particulière : l'ADN ne peut pas être véritablement dé-identifié, puisque la séquence est elle-même un identifiant. La gouvernance s'y appuie sur les contrôles d'accès et le consentement, pas sur l'anonymisation.

Choisir le bon jeu de données : une carte rapide

  • Utilisation et coût des médicaments au niveau population ? Claims.
  • Résultats cliniques détaillés dans un seul système ? EHR.
  • Pourquoi un sous-groupe a répondu différemment ? Génomique liée à l'EHR.
  • Signal de sécurité émergent ? FAERS / EudraVigilance / MAUDE, en gardant en tête que vous ne pouvez pas calculer de taux réels.
  • Qualité de lot et cause racine d'un rappel ? MES sous BPF.

Le réflexe du professionnel est de se demander, avant toute analyse : quel jeu de données a été conçu pour capter cela, et à quoi est-il structurellement aveugle ?

Points clés à retenir

  • Chaque jeu de données a une finalité et un angle mort. Les claims suivent l'argent, les EHR suivent le soin, les registres suivent les déclarations. Faites correspondre le jeu de données à la question, et nommez ce qu'il ne peut pas voir.
  • Les déclarations spontanées ne sont pas des taux. FAERS, EudraVigilance et MAUDE n'ont pas de dénominateur. Ne présentez jamais un décompte brut d'événements indésirables comme un taux d'incidence.
  • La qualité est mesurable. Utilisez conformance, complétude et plausibilité. Un chiffre de complétude de 64 % est un signal d'alerte de biais d'informed presence, pas seulement un nombre.
  • Le linkage repose sur des standards. OMOP CDM pour l'analyse observationnelle et FHIR pour l'échange sont les deux acronymes qui rendent des systèmes disparates interopérables.
  • La gouvernance diffère selon la géographie. Dé-identification HIPAA aux États-Unis, RGPD plus l'espace européen des données de santé en construction dans l'UE, et une génomique qui ne peut jamais être totalement anonymisée.