En résumé
Un jeu de règles rassemble des contrôles exécutés sur une base. Créé à partir d’un schéma, il démarre avec des centaines de contrôles tirés de sa structure et de son mapping — des contrôles ordinaires, que vous modifiez ou supprimez comme les vôtres. Un scan les exécute tous et produit un score ; quand un contrôle échoue, Investiguer affiche les lignes en cause.
À quoi ça sert
Un entrepôt se dégrade sans prévenir. Une alimentation change, une colonne se vide, un identifiant cesse de correspondre. Rien ne plante : les tableaux de bord continuent d’afficher des chiffres, simplement faux.
Un jeu de règles transforme cette surveillance en quelque chose qu’on relance. Plutôt que de découvrir le problème dans une analyse six mois plus tard, on l’attrape en relançant un scan.
C'est une fonctionnalité d'espace de travail
Les jeux de règles vivent dans l’entrepôt, pas dans un projet. La qualité d’une base concerne tous ceux qui l’utilisent : la contrôler une fois par base a plus de sens que de la recontrôler dans chaque projet.
Créer un jeu de règles à partir d’un schéma
Nouveau jeu de règles ouvre un formulaire : un Nom, un Identifiant, la Base de données à contrôler et le Schéma dont partir. Choisir la base propose automatiquement son schéma ; le formulaire annonce alors combien de contrôles seront ajoutés, et d’où ils viennent.
Ces contrôles sont écrits une seule fois, à la création. Ensuite, ce sont des contrôles comme les autres : vous les renommez, modifiez leur SQL, les désactivez ou les supprimez. Choisir Aucun (jeu de règles vide) démarre sans contrôle.
Issus du DDL — la structure, sur les tables brutes
Le DDL est la description des tables du schéma (colonnes, contraintes). Linkr en tire, pour chaque table : les colonnes existent-elles, chaque colonne NOT NULL est-elle bien remplie, la clé primaire est-elle unique, chaque clé étrangère pointe-t-elle vers une ligne qui existe.
Issus du mapping — le sens des données
Le mapping du schéma dit quelle table porte les patients, les séjours, les événements. Linkr en tire : les colonnes indispensables sont-elles renseignées, y a-t-il des séjours ou des événements sans patient, une fin antérieure au début, un événement avant la naissance ou plus de 60 jours après le décès, un âge hors de 0–130 ans, des codes non mappés, des valeurs sans unité, des doses négatives.
Sur OMOP CDM 5.4, cela représente environ 470 contrôles. Un contrôle du mapping déjà couvert par une contrainte du DDL n’est pas créé en double.
Pourquoi vérifier un NOT NULL déjà déclaré ?
Parce que la déclaration ne garantit rien. Une base faite de fichiers Parquet ou CSV n’applique aucune contrainte, et les chargements OMOP sautent souvent les scripts de contraintes pour aller plus vite. Le contrôle coûte peu ; une colonne obligatoire vide fausse toutes les analyses qui s’y fient.
Les contrôles du mapping suivent chaque base
Ils s’écrivent sur les relations standard de Linkr (linkr_patient, linkr_visit, linkr_event_…), pas sur les tables d’origine. Un même jeu de règles s’applique donc à deux bases qui partagent un schéma, même si l’une d’elles a adapté son mapping.
Conformité, complétude, plausibilité
Chaque contrôle porte une catégorie et, pour deux d’entre elles, une sous-catégorie. Elles suivent le cadre de Kahn et al. (2016), celui qu’utilise le Data Quality Dashboard d’OHDSI — c’est le vocabulaire commun de l’écosystème OMOP.
| Catégorie | La question | Sous-catégories |
|---|---|---|
| Conformité | Les données respectent-elles la structure et les formats attendus ? | Valeur, Relationnelle, Calculée |
| Complétude | Les données sont-elles là où on les attend ? | — |
| Plausibilité | Les valeurs sont-elles crédibles ? | Unicité, Atemporelle, Temporelle |
L’icône d’information à côté de Catégorie, dans l’éditeur, rappelle ces définitions. Pour ce que recouvre la qualité des données en santé, voir l’article La qualité des données.
Organiser les contrôles
Dans l’onglet Contrôles, la liste est rangée en groupes. Les contrôles générés arrivent dans le groupe de leur table ; ceux que vous écrivez, dans Autres contrôles. Une pastille donne la catégorie de chaque contrôle — bleu pour la conformité, teal pour la complétude, fuchsia pour la plausibilité — et l’en-tête d’un groupe compte ses contrôles actifs sur le total.
Échoué
12 lignes enfreignent la règle sur 48 210 (0,02 %)
Seuil 0 % : aucune violation tolérée
- Renommer ou Supprimer le groupe — clic droit sur l’en-tête du groupe. La suppression demande confirmation : supprimer ses contrôles avec lui, ou Garder les contrôles, qui passent dans « Autres contrôles ».
- Nouveau groupe — dans le menu + de la liste.
- Déplacer vers… — clic droit sur un contrôle, puis choix du groupe d’arrivée, d’« Autres contrôles » ou d’un nouveau groupe à nommer. Avec Sélection multiple, on déplace, active, désactive ou supprime plusieurs contrôles d’un coup.
- Filtrer et trier — le bouton de filtre restreint la liste par Origine (issu du DDL, du mapping, ou manuel) et par Catégorie, et trie les groupes : Ordre de la liste, A → Z ou Z → A.
Un contrôle désactivé reste dans la liste, barré, mais sort du scan et du score.
Un groupe vide est conservé
Un groupe créé avec Nouveau groupe reste dans la liste, même vide, en attendant qu’on y déplace un contrôle : il y affiche « Vide — clic droit sur un contrôle › Déplacer vers… ». Il est enregistré avec le jeu de règles et voyage avec lui.
Ajouter des contrôles
Le menu + de la liste propose trois entrées :
- Contrôle manuel — un contrôle vide, avec un exemple de requête à adapter.
- Depuis le DDL… et Depuis le mapping… — la liste des contrôles du schéma que ce jeu de règles ne contient pas encore, groupés par table, à cocher. C’est ainsi qu’on récupère un contrôle supprimé par erreur, ou qu’on complète un jeu de règles après une évolution du schéma.
Écrire un contrôle
Un contrôle est une requête SQL soumise à une seule contrainte : renvoyer une ligne, avec deux colonnes nommées violated_rows (les lignes qui enfreignent la règle) et total_rows (les lignes concernées par la règle).
SELECT
COUNT(*) FILTER (WHERE end_datetime < start_datetime)::BIGINT AS violated_rows,
COUNT(*)::BIGINT AS total_rows
FROM linkr_visitLinkr ne lit pas votre SQL : il lit ces deux nombres, en tire un pourcentage, et le compare au seuil. Toute la logique métier vous appartient.
L’éditeur — à droite dans la figure ci-dessus — a deux onglets. Calcul contient cette requête. Lignes en échec, facultatif, contient celle qui liste les lignes que le calcul compte comme violations — c’est elle qu’ouvre Investiguer. Les contrôles générés ont les deux. Une pastille orange signale une modification non enregistrée, et Enregistrer ou Annuler portent sur les deux requêtes à la fois.
Quatre réglages accompagnent les requêtes :
- Catégorie et Sous-catégorie — elles servent au classement et aux graphiques.
- Sévérité — erreur, avertissement ou information.
- Seuil (%) — le pourcentage de lignes en échec toléré, entre 0 et 100.
0signifie aucune tolérance. Une valeur vide ou hors de cette plage est signalée à côté du champ et n’est pas enregistrée.
Le bouton Tester, ou Ctrl/⌘ + Entrée dans l’onglet Calcul, exécute le contrôle sans lancer de scan complet et explique le résultat : combien de lignes enfreignent la règle, sur combien, et le seuil appliqué. Le même raccourci, dans l’onglet Lignes en échec, lance Investiguer. Sans base choisie, un message rouge le signale à côté du sélecteur de base.
Investiguer un échec
Un contrôle qui échoue dit combien de lignes posent problème, pas lesquelles. Investiguer — dans la barre de l’onglet Contrôles, ou dans le panneau de détail d’un résultat — ouvre l’onglet Investigation et y exécute la requête des lignes en échec : on voit directement les enregistrements en cause. Sans cette requête, c’est celle du calcul qui est ouverte.
L’onglet Investigation est une console SQL sur la base du jeu de règles : on peut y réécrire la requête, la relancer avec Exécuter, Ctrl/⌘ + Entrée (sélection ou ligne courante) ou Ctrl/⌘ + Maj + Entrée (tout l’éditeur). Chaque exécution affiche le nombre de lignes, la durée, et la date et l’heure d’exécution.
Lancer un scan et lire le résultat
Lancer le scan, dans l’onglet Résultats, exécute l’un après l’autre tous les contrôles actifs. Au-dessus du tableau, deux graphiques — Contrôles par catégorie et Taux d’échec par catégorie — que le bouton Graphiques masque ou affiche.
| Statut | Contrôle | Catégorie | Sous-catégorie | Table | % Violation | Sévérité |
|---|---|---|---|---|---|---|
| linkr_event_measurement : valeurs avec unité | Plausibilité | Atemporelle | linkr_event_measurement | 7.4% | ||
| linkr_visit : fin après début | Plausibilité | Temporelle | linkr_visit | 0.0% | ||
| note : colonnes | Conformité | Valeur | note | 0.0% | ||
| gender_concept_id non nul | Complétude | — | person | 0.0% | ||
| person : clé unique | Plausibilité | Unicité | person | 0.0% | ||
| visit_occurrence_id → visit_occurrence | Conformité | Relationnelle | measurement | 0.0% | ||
| linkr_event_drug : pas de dose négative | Plausibilité | Atemporelle | linkr_event_drug | — |
linkr_event_measurement : valeurs avec unité
Les valeurs numériques de linkr_event_measurement ont une unité
Le tableau donne, pour chaque contrôle : statut (OK, Échec, Erreur ou N/A), nom, catégorie, sous-catégorie, table, pourcentage en échec et sévérité ; survoler une icône en donne le libellé. Cliquer une ligne ouvre le panneau de détail : la barre de violation face au seuil, les compteurs, le temps d’exécution, Requête SQL — qui montre les deux requêtes — et Investiguer.
Le score est la proportion de contrôles réussis parmi ceux qui s’appliquent. Les contrôles sans objet — zéro ligne concernée, N/A — en sont exclus. Sa pastille est verte à partir de 95 %, ambre à partir de 80 %, rouge en dessous.
Un contrôle en erreur fait baisser le score
Un contrôle dont le SQL échoue — une table absente, une colonne renommée, une faute de frappe — compte dans le total mais jamais parmi les réussites. Le score baisse donc comme si les données étaient en cause. Devant un score qui chute sans raison, regardez d’abord s’il y a des lignes en statut Erreur : le panneau de détail donne le message.
Chaque scan est enregistré dans l’Historique des scans, consultable, rejouable à l’écran et effaçable. Un Tester isolé n’y figure pas : seuls les scans complets sont conservés.
Ce qu’il faut savoir avant de lancer
- Un scan peut être long. Les contrôles s’exécutent en série, et un jeu de règles créé à partir d’OMOP en compte plusieurs centaines. Désactivez ceux qui ne vous concernent pas plutôt que de les laisser ralentir chaque scan.
- Une base est indispensable. Elle est facultative à la création du jeu de règles, mais sans elle il n’y a rien à exécuter.
- Où s’exécutent les requêtes. En mode navigateur, dans le navigateur. En mode serveur, sur le serveur, contre la base : le navigateur ne fait qu’enchaîner les contrôles et ne charge jamais les données brutes. Voir Modes de déploiement.
- L’historique conserve le rapport complet de chaque scan. Sur des scans fréquents, il grossit : le bouton Effacer est là pour ça.
Partager un jeu de règles
Un jeu de règles est une entité comme les autres : il s’exporte, se versionne dans un dépôt git et se publie au catalogue. Son export contient tous ses contrôles — générés comme manuels, avec leurs deux requêtes, leur groupe et leur état actif ou désactivé — et une référence au schéma dont il est issu. Jamais les résultats, ni les données.
À l’import, la base contrôlée est retrouvée par son identité, si elle est installée. C’est ce qui permet à un ensemble de contrôles qualité OMOP éprouvé de circuler entre établissements et de s’appliquer tel quel à une autre base portant le même schéma. Voir Entités et partage.
Pour aller plus loin
- Schémas — le DDL et le mapping dont sont tirés les contrôles.
- Bases de données — rattacher un schéma à une base, et sa console SQL.
- La qualité des données — pourquoi les données brutes ne sont pas prêtes, et ce que ça demande.
- Pipelines ETL — qui disposent de leur propre comparaison source/cible.