+150 XP

Mesurer la qualité des données avec des métriques sectorielles

Un coordinateur d'essai clinique charge 4 200 dossiers de patients en oncologie. Sur le papier, l'ensemble semble complet. Mais 38 % des champs de stade tumoral sont vides, certains statuts HER2 indiquent « positve », et un patient pèse officiellement 6 kilos. Avant même le premier modèle, ce jeu de données vous ment déjà.

Cette leçon vous donne une méthode reproductible pour repérer ces mensonges. Nous utilisons trois dimensions de qualité des données sur lesquelles le monde biomédical s'appuie réellement (complétude, conformance et plausibilité) et nous notons un jeu de données oncologiques désordonné selon sa capacité à être analysé.

Pourquoi les données d'oncologie se dégradent de façon prévisible

Les données d'oncologie sont désordonnées pour des raisons structurelles, pas seulement par négligence.

  • Plusieurs sources fusionnent. Un seul enregistrement de registre tumoral peut provenir du EHR (Electronic Health Record, le dossier patient numérique de l'hôpital), du LIS (Laboratory Information System) et de comptes rendus d'anatomopathologie saisis en texte libre.
  • Les standards sont concurrents. La stadification du cancer peut suivre l'AJCC (American Joint Committee on Cancer) ou des systèmes plus anciens. Les diagnostics utilisent la CIM-10 (Classification internationale des maladies, 10e révision) ou la CIM-O-3 (la version spécifique à l'oncologie).
  • Délais. Un résultat de biomarqueur arrive des semaines après le diagnostic, laissant des champs temporairement vides.

Conséquence : vous ne pouvez pas faire confiance à un jeu de données parce qu'il « a toutes les colonnes ». Vous le mesurez.

Les trois dimensions, définies

Ces trois dimensions viennent directement du framework de Kahn pour la qualité des données EHR, largement cité et adopté par des réseaux de recherche comme OHDSI (Observational Health Data Sciences and Informatics). Voir l'article en accès libre sur la terminologie harmonisée d'évaluation de la qualité des données.

1. Complétude

Les valeurs sont-elles présentes là où elles devraient l'être ? Un champ peut être absent (jamais collecté) ou manquant (attendu mais vide). Ce sont deux problèmes différents.

2. Conformance

Les valeurs respectent-elles le format, le type et le vocabulaire requis ? Un champ HER2 doit contenir une valeur contrôlée (« Positive », « Negative », « Equivocal »), pas « positve » ni « 3+ peut-être ».

3. Plausibilité

Les valeurs sont-elles crédibles au regard de la réalité clinique ? Un patient adulte de 6 kg échoue à la plausibilité même si le champ est présent et numérique.

Un enregistrement peut réussir une dimension et échouer à une autre. C'est tout l'intérêt de les mesurer séparément.

Noter le jeu de données oncologiques désordonné

Prenons un exemple concret. Notre jeu de données : 4 200 dossiers de cancer du sein avec ces champs clés.

ChampProblème constaté
tumor_stage38 % vides
her2_statusfautes de frappe en texte libre, 12 % non conformes
patient_weight_kg3 % de valeurs implausibles
diagnosis_date1 % postérieures à death_date

Score de complétude

Complétude pour un champ :

completeness = (records with a valid non-null value) / (records where value is expected)

Pour tumor_stage : 62 % des 4 200 dossiers ont une valeur.

completeness(tumor_stage) = 2,604 / 4,200 = 0.62

Soit 62 %. En dessous de la plupart des seuils analytiques (les réseaux de recherche visent souvent 90 % ou plus pour les variables cliniques centrales, même s'il n'existe pas de standard universel unique).

Mais attention : certains vides sont légitimement « non applicables ». Pour une patiente dont le cancer a été détecté au stade pré-invasif, un stade complet peut ne pas s'appliquer. Donc séparez la complétude en « attendu mais manquant » (un vrai problème) et « non applicable » (sans conséquence). Si 400 de ces vides sont réellement non applicables :

adjusted completeness = 2,604 / (4,200 - 400) = 2,604 / 3,800 = 0.685

Maintenant 68,5 %. Toujours faible, mais honnête.

Score de conformance

her2_status doit correspondre à un vocabulaire contrôlé. Douze pour cent échouent.

conformance(her2_status) = (4,200 - 504) / 4,200 = 3,696 / 4,200 = 0.88

88 %. Les 504 enregistrements non conformes sont souvent récupérables : « positve », « POS » et « positive » peuvent être normalisés vers une seule valeur canonique. Les défauts de conformance sont fréquemment les moins coûteux à corriger parce qu'ils sont mécaniques.

Score de plausibilité

Deux contrôles ici :

  • Contrôle d'intervalle : patient_weight_kg entre environ 30 et 250 pour des adultes. 3 % échouent.
  • Contrôle de logique temporelle : diagnosis_date doit précéder death_date. 1 % échoue.
plausibility(weight) = (4,200 - 126) / 4,200 = 0.97
plausibility(date_logic) = (4,200 - 42) / 4,200 = 0.99

La plausibilité du poids est de 97 %, la logique de dates de 99 %. Les échecs sur les dates sont des signaux d'alerte : ils traduisent généralement une erreur de fusion de données, pas une vraie valeur extrême.

Transformer les scores en verdict de préparation

On ne fait pas une moyenne à l'aveugle. Pondérez les champs selon le besoin réel de vos analyses en aval.

Supposons que vous construisiez un modèle de prédiction de la réponse au traitement, et que tumor_stage et her2_status soient des prédicteurs essentiels. Un score de complétude de 68,5 % au niveau du champ tumor_stage est un blocage, pas une note de bas de page. Aucune propreté des données de poids ne compense un prédicteur clé manquant.

Une grille de préparation simple :

  • Vert (prêt) : tous les champs essentiels à 90 % ou plus sur chaque dimension.
  • Orange (conditionnel) : problèmes de conformance corrigeables, ou données manquantes qui peuvent être imputées ou exclues de façon transparente.
  • Rouge (non prêt) : complétude d'un champ essentiel sous le seuil, ou échecs systématiques de plausibilité suggérant un pipeline cassé.

Notre jeu de données est Rouge, à cause de la complétude de tumor_stage. Le problème de conformance her2 est Orange (corrigeable mécaniquement). Les échecs de logique de dates exigent une enquête avant toute autre chose, car ils laissent penser que la fusion elle-même est défectueuse.

Ce verdict est le livrable. « Rouge en raison de la complétude du stade et d'erreurs de logique de dates non résolues » est bien plus utile qu'un pourcentage global unique qui masque le défaut fatal.

🎬 [VIDEO: "Data Quality in Healthcare: The OHDSI Data Quality Dashboard" - youtube.com - démonstration d'un outil open source qui exécute des milliers de contrôles automatisés de conformance et de plausibilité sur des données de santé]

Vérification des acquis

1. Un champ de stade tumoral est vide parce que le résultat du biomarqueur n'était pas encore arrivé au moment de l'extraction des données, tandis qu'un autre champ n'a jamais été saisi par le système source. Quelle distinction cela illustre-t-il ?

2. Un champ de statut HER2 contient la saisie « positve » au lieu de « positive ». Quelle dimension de qualité des données ce défaut viole-t-il principalement ?

3. Un dossier patient indique un poids adulte documenté de 6 kilogrammes. Tous les champs requis sont remplis et la valeur est un nombre correctement formaté. Pourquoi ce dossier échoue-t-il quand même à un contrôle de qualité ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les réponses correctes. Pourquoi les données d'oncologie tendent-elles à se dégrader de façon prévisible et structurelle plutôt que par simple négligence ?

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les réponses correctes. Quel raisonnement la leçon emploie-t-elle pour justifier de mesurer la qualité des données plutôt que de faire confiance à un jeu de données qui paraît complet ?

Sélectionnez toutes les réponses correctes.

Automatiser les contrôles

Vous n'allez pas inspecter 4 200 dossiers à l'œil. Voici la logique d'un contrôle minimal de conformance et de plausibilité, en pseudocode de style Python.

python
VALID_HER2 = {"Positive", "Negative", "Equivocal"}

def score_record(r):
    flags = []
    # Conformance
    if r["her2_status"] not in VALID_HER2:
        flags.append("her2_nonconform")
    # Plausibilité : intervalle
    if not (30 <= r["patient_weight_kg"] <= 250):
        flags.append("weight_implausible")
    # Plausibilité : logique temporelle
    if r["diagnosis_date"] > r["death_date"]:
        flags.append("date_logic_fail")
    return flags

Exécutez cela sur l'ensemble du jeu de données, comptez les flags par règle, et vous obtenez automatiquement des scores de dimension au niveau du champ. Des outils comme le OHDSI Data Quality Dashboard font exactement cela à grande échelle, en exécutant des milliers de contrôles sur un modèle de données standardisé.

Benchmarks et standards sectoriels

Quelques repères pour 2026, tous à considérer comme du contexte, pas comme des règles strictes :

  • Les Common Data Models comptent. Un mapping vers OMOP (Observational Medical Outcomes Partnership) ou FHIR (Fast Healthcare Interoperability Resources, le standard HL7 d'échange de données de santé) vous permet de réutiliser des contrôles de qualité publiés plutôt que d'inventer les vôtres.
  • Des attentes réglementaires existent. Pour les données soutenant des dossiers de médicaments ou de dispositifs, la FDA américaine (Food and Drug Administration) et l'EMA (Agence européenne des médicaments) attendent une intégrité des données régie par les principes ALCOA+ : Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, Available. Notez le recouvrement : complétude et exactitude sont des attentes réglementaires, pas de simples raffinements analytiques.
  • L'examen des données de vie réelle s'intensifie. Le framework Real-World Evidence de la FDA traite explicitement de la fiabilité des données, ce qui renvoie directement à la conformance et à la plausibilité.

Il n'existe pas de pourcentage de complétude imposé par la loi. Ce que les régulateurs exigent, c'est que vous documentiez votre évaluation de qualité et votre traitement des défauts. Un Orange transparent est défendable. Un Rouge caché ne l'est pas.

Une remarque sur les données de dispositifs medtech

Les trois mêmes dimensions s'appliquent aux données générées par les dispositifs (un capteur de glycémie en continu, le journal d'une pompe à perfusion).

  • Complétude : trous dans une série temporelle de capteur (mesures perdues).
  • Conformance : horodatages dans le fuseau horaire et l'unité attendus.
  • Plausibilité : une glycémie de 900 mg/dL qui traduit probablement une défaillance du capteur, pas l'état d'un patient.

Pour les données de dispositifs à haute fréquence, la plausibilité devient souvent la préoccupation dominante, car les capteurs produisent des valeurs présentes, bien formatées, mais physiologiquement impossibles.

Points clés

  • Mesurez les trois dimensions séparément. Complétude, conformance et plausibilité détectent des défaillances différentes. Un enregistrement peut être complet mais implausible, ou bien formaté mais vide là où cela compte.
  • Notez les champs, pas seulement les jeux de données. Une complétude de 68,5 % sur tumor_stage (un prédicteur essentiel) rend le jeu de données Rouge, quelle que soit la propreté du reste.
  • Distinguez « manquant » de « non applicable ». L'ajustement du dénominateur a transformé 62 % en un 68,5 % honnête et a évité de pénaliser des vides légitimes.
  • La conformance est souvent peu coûteuse, les échecs de plausibilité sont souvent des avertissements. Les fautes de frappe se normalisent facilement ; une diagnosis_date postérieure à death_date signale généralement une fusion de données défectueuse.
  • Documentez, ne cachez pas. Les régulateurs (FDA, EMA) et les réseaux de recherche (OHDSI) attendent une évaluation de qualité transparente. Un Orange défendable vaut mieux qu'un Rouge dissimulé.