7 erreurs d'extraction de captures d'écran de DSE qui coûtent aux
équipes cliniques des données irrécupérables

Pourquoi l'extraction par capture d'écran échoue — et ce n'est pas qu'une erreur utilisateur

Quand vous avez besoin des résultats de laboratoire d'une cohorte de 200 patients pour une étude rétrospective, le DSI vous offre rarement un export propre. La plupart des coordinateurs de recherche clinique (CRC) et gestionnaires de données travaillent avec ce qu'ils ont : des captures d'écran de panneaux de résultats, prises depuis Epic ou Cerner lors d'une revue de dossier. La logique est simple : « Je vois la créatinine sur cet écran. Si je l'extrais, j'aurai les valeurs de créatinine pour mon analyse. »

Cette logique est erronée. Non pas parce que la valeur n'est pas là, mais parce que l'extraire avec précision nécessite de résoudre plusieurs problèmes qu'une simple capture d'écran ne peut jamais résoudre. Le modèle de gestion de la qualité des données de l'AHIMA, qui régit la gestion des données de santé tout au long de leur cycle de vie — de la collecte à l'application en passant par l'entreposage — identifie quatre dimensions de la qualité des données : exactitude, exhaustivité, cohérence et actualité. Une capture d'écran d'un panneau DSI échoue sur les trois premières avant même que l'extraction ne commence. Les données sont là, mais non structurées. L'intervalle de référence est là, mais il appartient à un laboratoire, pas à celui du couloir. Le contexte de la rencontre est présent à l'écran mais s'évapore dès que vous enregistrez le fichier image.

Voici sept erreurs spécifiques — le genre qui ne sont évidentes qu'après avoir constitué un jeu de données et découvert, six mois plus tard, que les chiffres ne concordent pas. Chacune a une cause racine plus profonde que le symptôme, et chacune a une correction qui change le résultat.

Erreur n°1 : Supposer que toute capture d'écran du DSI est lisible par machine

C'est l'erreur qui prépare toutes les autres. Vous prenez une capture d'écran du bilan métabolique complet d'un patient. Sur votre écran, à la résolution de votre moniteur, chaque valeur est nette : Glucose 102, Créatinine 1,3, DFGe 57. Vous la soumettez à un outil OCR et il renvoie « Glucose 102 », « Créatinlne 1,3 », « DFGe S7 ». Proche. Mais faux.

La cause n'est pas un mauvais moteur OCR. C'est l'écart de résolution entre ce que vos yeux voient et ce que l'outil d'extraction traite. La plupart des captures d'écran du DSI sont prises à la résolution de l'écran — 96 DPI sur un moniteur standard, peut-être 150 DPI sur un écran haute densité. L'OCR traditionnel a été conçu pour des documents scannés à 300 DPI ou plus. Plus la résolution est faible, plus la confusion au niveau des caractères est probable : « BUN » devient « 8UN », « Mg » devient « Mg » (identique pour l'outil), et « 1,3 » dans une petite police devient ambigu entre 1,3, 1,8, 1,9.

Ce problème s'aggrave lorsque vous travaillez avec des captures défilantes — ces longues captures d'écran où vous avez fait défiler un panneau de laboratoire qui ne tient pas sur un seul écran et utilisé un outil d'assemblage pour combiner plusieurs images. L'assemblage introduit de légers artefacts d'alignement aux jonctions. Si une valeur de laboratoire tombe sur une jonction, l'outil d'extraction voit un caractère brisé. La valeur est soit erronée, soit totalement manquante, sans aucun indicateur d'erreur pour vous le dire.

La correction : Avant de vous lancer dans l'extraction par capture d'écran, auditez votre source. Si vous capturez des écrans spécifiquement pour l'extraction, réglez l'affichage sur 100 % et capturez à la résolution maximale de votre moniteur. Si vous travaillez avec des captures prises par quelqu'un d'autre — un scénario courant dans les études multi-sites — testez la précision de l'extraction sur un échantillon aléatoire de 20 images avant de traiter l'ensemble du lot. Si le taux d'erreurs au niveau des caractères dépasse 1 %, la qualité de la capture est le goulot d'étranglement, pas l'outil d'extraction. Dans ce cas, l'extraction ciblée de champs — où vous spécifiez exactement les valeurs dont vous avez besoin et l'IA les localise par compréhension sémantique plutôt que par OCR pixel par pixel — gère mieux les variations de résolution qu'un OCR pleine page.

Erreur n°2 : Tout extraire au lieu de répondre à votre question de recherche

Vous avez besoin de trois valeurs par patient : créatinine à l'admission, créatinine à la sortie, et troponine maximale. Vous fournissez la capture à un outil OCR. Il lit tout le panneau de laboratoire — 28 valeurs, plages de référence, horodatages de prélèvement, nom du prescripteur, note de bas de page « Résultat précédent » — et vous livre un mur de texte. Vous voilà à faire la même recherche manuelle dans 200 dumps OCR que vous vouliez éviter, sauf que vous fouillez un texte au lieu d'une image.

La cause profonde est un décalage entre la conception de l'outil et la tâche. L'OCR standard est conçu pour numériser des documents — transformer une image de texte en texte. Il n'a jamais été conçu pour répondre à « quelle était la créatinine à l'admission de ce patient ? ». Cette question nécessite de comprendre quelle valeur sur la page correspond à quel concept clinique, et d'ignorer le reste. Un outil OCR qui extrait les 28 valeurs ne vous a pas épargné 28 unités de travail. Il a créé 25 unités de bruit à filtrer pour trouver les 3 dont vous avez besoin.

Une revue systématique dans JCO Clinical Cancer Informatics a décrit un outil appelé ExtractEHR qui atteignait plus de 98 % de sensibilité pour les événements indésirables biologiques — contre 0 à 21 % pour l'extraction manuelle. La différence n'était pas un meilleur moteur OCR. C'était que l'outil extrayait des points de données spécifiques et prédéfinis plutôt que de déverser tout le contenu de la page. Lorsque vous définissez ce dont vous avez besoin avant l'extraction — « Créatinine à l'admission », « Créatinine à la sortie », « Troponine maximale » — vous inversez le flux de travail. Au lieu de tout extraire puis de chercher, vous cherchez d'abord (en définissant vos champs) et n'extrayez que les résultats.

La correction : Notez vos variables de recherche exactes avant toute extraction. Pas « valeurs de laboratoire » — des champs spécifiques avec des définitions précises. « Créatinine à l'admission » signifie la première valeur de créatinine dans les 24 heures suivant l'admission, pas la créatinine d'un séjour quelconque. Si votre outil d'extraction crée une ligne par patient avec exactement ces colonnes, le problème est résolu. S'il crée un dump texte de 28 lignes par patient à analyser, vous n'avez rien automatisé. Les outils prenant en charge l'extraction de colonnes personnalisées — où vous saisissez les noms de champs souhaités et le modèle ne trouve que ces valeurs — sont conçus précisément pour ce flux de travail. Vous définissez la structure de sortie ; l'extraction la remplit. Pour une présentation plus détaillée de cette approche, voir comment l'extraction ciblée de données cliniques diffère de l'OCR à usage général.

Erreur n°3 : Ignorer les variations d’unités et d’intervalles de référence entre laboratoires

Un patient a deux bilans biologiques dans votre jeu de données — l’un du laboratoire de l’hôpital d’admission, l’autre d’un laboratoire de référence utilisé par la consultation externe. Le laboratoire hospitalier rapporte la créatinine en mg/dL avec un intervalle de référence de 0,7-1,2. Le laboratoire de référence rapporte la créatinine en µmol/L avec un intervalle de référence de 62-106. Votre outil d’extraction capture fidèlement les deux valeurs : « 1,3 » et « 115 ». Les deux sont légèrement élevées par rapport à leurs intervalles respectifs. Si vous fusionnez ces deux valeurs dans une seule colonne « Créatinine » sans normaliser les unités, votre analyse les traite comme des nombres comparables — et une créatinine de 115 dans votre tableur ressemble à une insuffisance rénale sévère à côté d’une créatinine de 1,3, alors qu’en réalité elle correspond approximativement à 1,3 mg/dL une fois convertie.

Cette erreur est particulièrement dangereuse car elle ne produit pas d’erreur évidente. Rien ne plante. Aucun signalement de valeur aberrante ne se déclenche (115 est une créatinine plausible pour un patient en insuffisance rénale aiguë). L’erreur est structurelle : votre jeu de données contient désormais des valeurs dans deux unités différentes, et chaque analyse en aval — moyennes, régressions, courbes de Kaplan-Meier — est silencieusement contaminée. Un livre blanc du NIH Collaboratory de 2015 sur la qualité des données des DSE a spécifiquement signalé ce problème, notant que les systèmes de DSE des soins intensifs et hospitaliers enregistrent fréquemment le même élément clinique dans des unités différentes, et que « les unités sont implicitement considérées comme identiques » est l’une des hypothèses d’extraction de données les plus courantes qui s’avère fausse.

L’intervalle de référence est un problème distinct. Si le laboratoire A indique « H » (Élevé) à côté d’une créatinine de 1,3 parce que leur limite supérieure est 1,2, et que le laboratoire B indique la même créatinine de 1,3 comme normale parce que leur limite supérieure est 1,3, le drapeau « H » est une propriété du laboratoire, pas du patient. Extraire les valeurs signalées sans l’intervalle de référence associé crée une illusion de signification clinique là où il n’y en a pas — ou l’inverse, une valeur jugée normale par le seuil d’un laboratoire mais en réalité anormale selon les directives standard.

La correction : Documentez les conventions d’unités et les intervalles de référence dans le cadre de votre protocole d’extraction, et non comme une étape de nettoyage des données a posteriori. Pour les études multi-sites, cela signifie créer une table de référence des laboratoires qui associe chaque établissement source à ses unités et intervalles standard, puis appliquer la conversion d’unités et la normalisation des intervalles pendant l’extraction — et non pendant l’analyse, moment où les valeurs brutes spécifiques au laboratoire peuvent déjà avoir été agrégées en statistiques récapitulatives impossibles à démêler. Certains workflows d’extraction permettent de définir des Colonnes calculées — des règles qui transforment les valeurs pendant l’extraction, comme convertir toutes les valeurs de créatinine en une seule unité — afin que le jeu de données de sortie soit déjà normalisé.

Erreur n°4 : Perdre le contexte de la rencontre lors de l'extraction des valeurs

Le DPI d'un même patient peut contenir une créatinine mesurée à l'admission (élevée en raison d'une déshydratation), une créatinine mesurée 48 heures plus tard (normalisée après apport liquidien) et une créatinine mesurée à la sortie (stable). Trois valeurs, un même patient, trois significations cliniques différentes. Si votre processus d'extraction capture « Créatinine : 2,1 ; 1,1 ; 0,9 » sans préserver à quelle rencontre appartient chaque valeur, vous perdez la capacité de distinguer un patient qui s'est amélioré d'un patient arrivé avec une fonction rénale normale et qui s'est détérioré — la trajectoire clinique disparaît.

Cette erreur survient car une capture d'écran ne montre que ce qui est visible sur un écran à un instant donné — et non la structure relationnelle qui lie chaque valeur de laboratoire à un horodatage de rencontre, un prescripteur et un contexte clinique. La capture du panel de laboratoire affiche « Créatinine 1,3 » et en dessous « Résultat précédent : Créatinine 1,1 (01/08/2026). » Si votre outil d'extraction lit ces deux éléments comme deux valeurs consécutives dans une liste — « 1,3 ; 1,1 » — vous venez de mélanger une valeur actuelle avec un comparateur historique. Votre jeu de données indique désormais que ce patient a deux valeurs de créatinine, alors qu'une seule appartient à la rencontre actuelle. Dans une étude sur l'évolution de la fonction rénale, cela devient impossible à distinguer d'une véritable seconde mesure.

Cela s'aggrave avec les comptes rendus de radiologie et d'anatomopathologie, où un même patient peut avoir une imagerie pré-interventionnelle, un constat peropératoire et un suivi post-sortie — tous contenus dans des documents distincts avec des identifiants de rencontre distincts. Un processus d'extraction qui ne préserve pas les métadonnées au niveau de la rencontre produit une liste plate de valeurs sans possibilité de reconstruire la chronologie clinique.

La correction : Définissez des colonnes de métadonnées au niveau de la rencontre dans votre modèle d'extraction — NIP patient, Date de rencontre, Heure de prélèvement du spécimen — et extrayez-les en même temps que chaque valeur de laboratoire. Chaque ligne de votre sortie doit représenter exactement un résultat de laboratoire issu d'une rencontre pour un patient. Si un patient a trois valeurs de créatinine sur trois rencontres, vous devez obtenir trois lignes, chacune avec un identifiant de rencontre unique. C'est l'inverse de l'approche « une ligne par patient », et c'est la seule structure qui préserve la trajectoire clinique. Pour les études où vous devez extraire des données de dizaines de rencontres par patient — courant dans la recherche longitudinale — l'extraction par lots avec granularité au niveau de la rencontre maintient la structure relationnelle intacte.

Erreur n°5 : La vérification manuelle, un faux filet de sécurité

Après avoir extrait les valeurs de laboratoire de 200 captures d'écran, vous faites ce qui semble responsable : vous vérifiez visuellement les valeurs extraites par rapport aux images sources. Vous contrôlez 10 % des enregistrements. L'idée est que l'œil humain rattrape ce que la machine manque. Les preuves disent le contraire.

Les recherches sur l'inspection visuelle humaine dans diverses disciplines — des données cliniques au contrôle qualité en fabrication — ont documenté des taux d'erreur dans la vérification manuelle allant de 16,4 % à 30,0 %. Cela signifie qu'un relecteur humain qui vérifie les valeurs de laboratoire extraites par rapport aux captures d'écran source manque environ une erreur sur cinq, et en introduit parfois de nouvelles en lisant mal une valeur correctement extraite. Le problème s'intensifie avec le volume : après avoir examiné 20 panels de laboratoire Epic quasi identiques, votre cerveau cesse de faire la différence entre « Na 139 » et « Na 139 » — les deux semblent corrects car le motif est si familier, même si l'un pourrait être une valeur de potassium mal étiquetée dans le résultat d'extraction.

La cause structurelle est que la vérification manuelle demande à un humain de faire ce pour quoi les humains sont mauvais : une reconnaissance de motifs monotone et à volume élevé, sans tolérance pour les variations d'attention. Un coordinateur de recherche clinique qui vérifie 200 panels de laboratoire sur deux après-midis n'opère pas à un niveau de vigilance maximal à la deuxième heure. Le passage de vérification détecte certaines erreurs de transposition, mais manque systématiquement les erreurs de contexte — une valeur placée dans la mauvaise colonne, un intervalle de référence interprété comme une valeur de résultat — car celles-ci ne semblent pas « fausses » lorsqu'elles sont vérifiées isolément. Elles ne deviennent visibles que lorsque vous essayez d'utiliser les données.

La correction : Remplacez la vérification par échantillonnage par une validation structurelle. Définissez des règles que votre résultat d'extraction doit satisfaire : les valeurs de créatinine doivent être des nombres positifs, l'eGFR doit être compris entre 1 et 200, les horodatages de prélèvement doivent se situer dans la plage de dates de la consultation. Appliquez ces règles à 100 % des enregistrements extraits, pas à un échantillon de 10 %. Signalez les violations pour examen humain — mais maintenant, l'humain enquête sur une anomalie plutôt que de comparer monotonement 200 lignes de données, ce qui est une tâche cognitive fondamentalement différente avec un taux d'erreur bien plus faible. Pour une perspective plus large sur pourquoi la vérification manuelle des données échoue à grande échelle, l'écart entre vérifier et valider est toute l'histoire.

Erreur n°6 : Propagation par copier-coller entre jeux de données

Vous extrayez des valeurs de laboratoire dans Excel. La feuille 1 est l'extraction maîtresse. La feuille 2 est le sous-ensemble d'analyse — vous copiez la colonne de créatinine de la feuille 1. La feuille 3 sert à l'analyse de Kaplan-Meier — vous copiez la colonne de créatinine de la feuille 2. Trois mois plus tard, quelqu'un découvre que la créatinine du patient n°47 a été saisie comme 13,0 au lieu de 1,30. C'est faux dans la feuille 1. Mais lesquelles des feuilles 2 et 3 contiennent aussi l'erreur ? La feuille 2 a-t-elle été copiée avant ou après la correction de la feuille 1 ? Lorsque vous mettez à jour la feuille 1, les feuilles 2 et 3 se mettent-elles à jour automatiquement, ou conservent-elles les anciennes valeurs ? Si vous avez partagé la feuille 2 avec un collaborateur qui a construit sa propre analyse dessus, comment propagez-vous la correction ?

Ce n'est pas un échec d'extraction de données — c'est un échec de gestion des données que les outils d'extraction n'empêchent pas mais que les flux d'extraction rendent inévitable. Le Quick Safety Issue 10 de la Joint Commission sur les erreurs de copier-coller dans les DSE a identifié que la propagation par copier-coller est l'un des principaux contributeurs aux erreurs de documentation clinique, et l'ECRI Institute a constaté que les erreurs de documentation représentent 72 % des responsabilités pour faute liées aux DSE. La même dynamique — une erreur se propageant silencieusement à travers plusieurs fichiers dérivés — s'applique à l'identique aux données de recherche extraites, avec le risque supplémentaire qu'aucun incident de sécurité des patients ne déclenche la découverte. L'erreur reste dans un tableur jusqu'à ce qu'un relecteur de revue remette en question une valeur aberrante invraisemblable, ou jusqu'à ce que l'analyse construite sur l'erreur soit publiée et ne puisse être retirée sans rétracter l'article.

La correction : Maintenez une source unique de vérité pour les données extraites. Le fichier d'extraction maître est l'enregistrement canonique. Tous les fichiers d'analyse y font référence — via des feuilles liées, des importations scriptées ou des requêtes de base de données — plutôt que de contenir leurs propres copies. Si une valeur est corrigée dans le fichier maître, la correction se propage automatiquement à chaque analyse. Cela demande de la discipline, pas de la technologie — mais c'est une discipline qui se rentabilise dès la première fois que vous devez corriger une valeur sans avoir à auditer six fichiers dérivés pour trouver où l'erreur s'est propagée. Pour les équipes gérant une revue de dossiers à grande échelle, le coût de l'absence d'une source unique de vérité s'accroît avec chaque dossier ajouté à la revue.

Erreur n°7 : Normaliser le taux d'erreur — quand 5 % devient acceptable

C'est la méta-erreur qui rend toutes les autres erreurs permanentes. Après une première extraction affichant 95 % de précision, l'équipe l'accepte. 95 %, c'est bien. Le processus manuel précédent atteignait peut-être 90 %. Le jeu de données est constitué, l'analyse est lancée, le manuscrit est soumis. Un taux d'erreur de 5 % sur 200 patients signifie que 10 patients ont au moins une valeur de laboratoire incorrecte dans le jeu final. Si ces 10 patients se trouvent dans le bras traitement de votre analyse, ou s'il s'agit des patients les plus malades (dont les dossiers sont les plus complexes et donc les plus sujets aux erreurs), cette erreur de 5 % n'est pas aléatoire — elle est systématiquement biaisée.

Le piège de la normalisation a une deuxième dimension : les types d'erreurs qui survivent à la normalisation sont les pires. Les erreurs de transposition — un échange de chiffres dans une valeur de laboratoire — produisent des valeurs aberrantes qui déclenchent des alertes lors de l'analyse. Une créatinine impossible de 130 mg/dL est détectée. Mais une valeur de laboratoire placée dans la mauvaise colonne de consultation, ou une plage de référence extraite comme valeur de résultat, ou une conversion d'unité jamais appliquée — celles-ci ne produisent pas de valeurs aberrantes. Elles produisent des valeurs plausibles qui s'inscrivent dans les plages attendues et passent tous les contrôles automatisés, précisément parce qu'il s'agit de valeurs cliniques réelles appartenant au mauvais contexte. Une analyse des réclamations de 2020 par The Doctors Company a révélé que le pourcentage de réclamations alléguant que les DSE ont contribué à des préjudices pour les patients est passé de 0,35 % en 2010 à 1,62 % en 2018. Le problème lié à l'utilisateur le plus courant était « informations incorrectes » (13 %) — des données qui semblaient correctes mais ne l'étaient pas.

La correction : Fixez des objectifs de précision avant l'extraction, pas après. Définissez ce que « précis » signifie pour votre question de recherche spécifique — non pas comme un pourcentage global, mais comme des exigences au niveau des champs. Les valeurs de créatinine doivent correspondre à la source à 0,1 mg/dL près. Les dates de consultation doivent correspondre exactement, pas approximativement. Les plages de référence doivent être vérifiées en tant que plages, et non extraites accidentellement comme des résultats. Exécutez des règles de validation sur les données extraites et calculez les taux d'erreur par champ. Un jeu de données précis à 95 % dans l'ensemble mais à 80 % sur le champ dont dépend votre critère principal n'est pas un jeu de données à 95 % de précision — c'est un jeu de données non fiable pour votre étude. Revenez en arrière et corrigez l'extraction pour ce champ spécifiquement.

Ce qui fonctionne vraiment : cinq décisions qui changent le résultat

Chaque erreur ci-dessus a une correction symétrique. Ensemble, elles forment un protocole d'extraction qui ne coûte rien mais évite les défaillances en aval qui rendent les jeux de données peu fiables.

1. Définissez vos champs avant toute extraction. Pas « valeurs de laboratoire » — des variables spécifiques avec des définitions précises, des unités et des plages attendues. Si vous avez besoin de la créatinine à l'admission, définissez-la comme « première créatinine sérique enregistrée dans les 24 heures suivant l'admission, en mg/dL ». La spécificité force l'extraction à cibler, pas à déverser.

2. Conservez le contexte du séjour comme colonne, pas comme convention. Chaque ligne extraite nécessite un ID patient, un ID séjour et un horodatage de prélèvement. Sans ces trois colonnes, votre jeu de données ne peut pas distinguer deux valeurs de créatinine du même patient prélevées à 48 heures d'intervalle — exactement la distinction dont votre analyse dépend.

3. Normalisez les unités lors de l'extraction, pas en post-traitement. Si le laboratoire A rapporte en mg/dL et le laboratoire B en µmol/L, appliquez la conversion lors de l'extraction. Une colonne calculée qui transforme toutes les valeurs en une seule unité avant l'assemblage du jeu de données signifie que vous n'aurez jamais à vous demander si une créatinine de 115 est une insuffisance rénale sévère ou simplement une unité différente.

4. Validez structurellement, pas par vérification ponctuelle. Des contrôles basés sur des règles sur 100 % des enregistrements — nombres positifs là où ils doivent être, horodatages dans les fenêtres de séjour, DFGe dérivé uniquement des valeurs de créatinine dans la même ligne — détectent plus d'erreurs qu'une vérification ponctuelle humaine pour une fraction du coût de main-d'œuvre. Réservez la relecture humaine aux exceptions signalées, pas à la vérification de routine.

5. Un fichier maître, zéro copie. Chaque analyse référence le jeu de données canonique. Les corrections se propagent automatiquement. Les fichiers dérivés sont des scripts, pas des tableurs statiques.

FAQ

L'IA peut-elle extraire de manière fiable les valeurs de laboratoire à partir de captures d'écran de DSE ?

Oui — mais seulement si vous définissez ce que vous voulez qu'elle trouve. Nourrir une capture d'écran à un moteur OCR générique en espérant obtenir des données structurées est l'erreur mentionnée au point #2 ci-dessus. L'approche fiable est l'extraction ciblée : vous spécifiez les champs dont vous avez besoin (par exemple, « Créatinine à l'admission », « Créatinine à la sortie ») et le modèle localise ces valeurs en comprenant leur signification, sans lire chaque caractère de la page séquentiellement. Cette approche sémantique gère les variations de résolution et de format sur lesquelles l'OCR basé sur les pixels échoue.

Quelle est la cause principale des valeurs de laboratoire extraites incorrectes ?

La perte de contexte — soit le contexte de l'unité/plage de référence (Erreur #3), soit le contexte de la rencontre (Erreur #4). Une valeur n'est presque jamais « fausse » isolément. Elle est fausse parce qu'elle appartient à un laboratoire différent, une rencontre différente, ou un système d'unités différent de la colonne où elle a atterri. Corrigez le contexte, et la plupart des « erreurs d'extraction » s'avèrent être structurelles, et non techniques.

Comment gérer les captures d'écran de DSE provenant de plusieurs systèmes hospitaliers différents ?

Chaque système de DSE — Epic, Cerner, Meditech — formate les panels de laboratoire différemment. Une valeur de créatinine peut apparaître sous « CHIMIE » dans un système et sous « BPC » (Bilan Protéique Complet) dans un autre. L'approche d'extraction doit être indépendante du format — localisant les valeurs par leur signification clinique plutôt que par leur position sur la page. C'est pourquoi l'OCR basé sur des modèles (qui cherche la créatinine à des coordonnées de pixels spécifiques) échoue sur des ensembles de données multi-sites, et pourquoi l'extraction sémantique (qui trouve « créatinine » où qu'elle apparaisse sur la page) ne le fait pas. Avant d'extraire, construisez un mappage de champs qui définit ce que vous cherchez en termes cliniques (« Créatinine sérique, mg/dL »), et non en termes de position.

La loi HIPAA affecte-t-elle la façon dont je peux extraire des données à partir de captures d'écran de DSE ?

Oui — mais d'une manière spécifique qui est pertinente pour le choix de l'outil. La loi HIPAA exige que les informations de santé protégées (PHI) soient traitées avec des garanties administratives, physiques et techniques (Règle de sécurité, 45 CFR Partie 164 Sous-partie C). Lorsque vous envoyez des captures d'écran de DSE à un outil d'extraction basé sur le cloud, vous transmettez des PHI à un tiers. Cela nécessite un contrat d'association de services (BAA) si l'outil traite ou stocke les images. Avant d'utiliser un outil d'extraction pour des données cliniques, confirmez s'il propose un BAA et si les fichiers téléchargés sont conservés après le traitement. Les outils qui traitent et suppriment plutôt que de stocker présentent un risque moindre du point de vue de la conformité. Ceci n'est pas un avis juridique ; consultez le comité d'éthique (IRB) et le responsable de la confidentialité de votre établissement pour votre étude spécifique.

Que faire si mes valeurs de laboratoire proviennent de rapports papier scannés, et non de captures d'écran du DSE ?

Les rapports scannés ajoutent une couche supplémentaire de dégradation : artefacts papier, distorsion d'angle de numérisation et couches OCR plus anciennes pouvant être altérées. Les erreurs fondamentales restent les mêmes, mais le problème de résolution (Erreur n°1) est amplifié. Si vous travaillez avec des scans, une approche basée sur un modèle de vision qui lit les documents comme le ferait un humain — en comprenant le contenu de manière sémantique plutôt que caractère par caractère — gère mieux les artefacts de numérisation que l'OCR traditionnel. Mais quel que soit l'outil, testez toujours d'abord sur vos pires documents (impression pâle, annotations manuscrites, pages inclinées), pas sur les plus nets.

Partez de votre question de recherche. Remontez jusqu'aux champs qui y répondent. Extrayez uniquement ceux-ci. Les sept erreurs ci-dessus sont toutes des conséquences en aval de l'omission de cette étape.