Pourquoi les données cliniques — déjà numériques —
sont encore extraites à la main

Les deux mondes parallèles de la documentation clinique

La documentation clinique existe dans deux écosystèmes d'information qui communiquent à peine. Le premier est celui des données structurées : cases à cocher, menus déroulants, boutons radio. Les codes CIM-10 qui classent un diagnostic. Les codes CPT qui décrivent une procédure. Les valeurs de laboratoire qui s'insèrent dans un champ de base de données — hémoglobine 12,3 g/dL, créatinine 0,9 mg/dL. C'est le monde que les DSE ont été conçus pour gérer. Il est consultable, interrogeable, exploitable. C'est aussi, en volume et en richesse clinique, le petit bassin.

Le second monde est celui des données non structurées : la prose narrative que les cliniciens produisent réellement lorsqu'ils décrivent ce qu'ils ont vu, pensé et fait. Le compte rendu radiologique qui dit "il existe un nodule spiculé de 1,2 cm dans le lobe supérieur droit, avec rétraction pleurale associée — biopsie sous guidage TDM recommandée." Le résumé de sortie qui relate une hospitalisation de 12 jours, des symptômes initiaux aux complications en passant par les instructions post-sortie. Le compte rendu opératoire qui décrit, en 800 mots de détails chirurgicaux, exactement quels vaisseaux ont été pontés, avec quels greffons, dans quelles conditions. La note d'évolution qui capture l'évaluation évolutive d'un clinicien sur trois quarts de travail.

Ce second monde — le monde narratif — contient environ 80 % de toutes les données cliniquement significatives du dossier de santé. Il porte le raisonnement derrière la prise de décision, la nuance que les codes diagnostiques aplatissent, le contexte qui rend une valeur de laboratoire exploitable plutôt qu'un simple chiffre. Et il est, par défaut, invisible pour tous les outils de reporting, plateformes d'analyse et flux de travail automatisés de l'hôpital.

Le monde structuré répond au "quoi" en raccourci. Le monde non structuré répond au "pourquoi, ce que cela signifie et ce qui devrait se passer ensuite." Le problème est que les machines ne peuvent lire que le premier.

Pourquoi le DSE n'a pas résolu ce problème

Depuis la loi HITECH de 2009, qui a fait passer l'adoption du DSE de 9 % à plus de 90 % des hôpitaux américains, une hypothèse persiste : les dossiers de santé électroniques auraient dû résoudre le problème d'accessibilité des données. Si l'information clinique est numérique, elle devrait être lisible par machine. Si elle est lisible par machine, elle devrait être interrogeable. Si elle est interrogeable, l'extraction manuelle devrait être obsolète.

L'hypothèse échoue dès la première étape. Les DSE ne sont pas des systèmes de connaissances cliniques. Ce sont des bases de données transactionnelles optimisées pour la facturation, conçues à une époque où l'usage principal de la numérisation d'un épisode de soins était la génération d'une demande de remboursement. La décision d'ingénierie fondamentale intégrée dans chaque plateforme majeure de DSE — Epic, Cerner, Meditech, Allscripts — est que les récits cliniques sont stockés comme des pièces jointes non structurées, et non comme des champs structurés. Un compte rendu radiologique généré dans le PACS de l'hôpital est attaché au dossier patient. Un compte rendu de sortie tapé dans une zone de texte libre est enregistré comme un bloc de texte. Un compte rendu opératoire est téléchargé sous forme de PDF.

Le DSE stocke ces documents. Il ne les analyse pas. Il n'indexe pas leur contenu. Il ne fait pas correspondre l'expression « nodule spiculé de 1,2 cm dans le lobe supérieur droit » à un élément de données structuré qu'une requête pourrait récupérer. Du point de vue d'une base de données, le compte rendu radiologique, le compte rendu de sortie et le compte rendu opératoire se trouvent dans la même catégorie qu'une copie numérisée d'un dossier papier de 1998 : numérisés mais non structurés, stockés mais non consultables.

Une étude publiée dans le Journal of Medical Internet Research (2025) a examiné le chevauchement d’informations entre les codes structurés et les notes en texte libre de 1,8 million de patients. Elle a révélé que les données structurées seules — codes CIM, codes d’actes, résultats de laboratoire — ne capturaient qu’une fraction du tableau clinique. Les notes en texte libre contenaient des « descriptions détaillées rendant compte des nuances des soins aux patients ». Les champs structurés du DSE vous indiquaient que le patient avait subi un pontage aorto-coronarien (PAC). Le compte rendu opératoire vous disait comment ce PAC s’était déroulé — ce qui importe énormément pour la mesure de la qualité, l’ajustement des risques et la recherche clinique.

Ce n’est pas un échec d’un éditeur de DSE en particulier. C’est une conséquence de ce pour quoi les DSE ont été conçus. Ils ont été construits pour capturer des données structurées à des fins de facturation et de reporting réglementaire. Ils n’ont pas été conçus pour extraire du sens à partir d’un récit. Le fait que 80 % des données cliniques résident dans du texte libre n’est pas un bug — c’est la conséquence naturelle du fait que les cliniciens documentent les soins comme les humains communiquent des informations complexes : en phrases, pas dans des listes déroulantes.

La main-d'œuvre d'abstraction dont personne ne parle

Parce que les DSE stockent les récits cliniques comme des blocs non consultables, les hôpitaux emploient toute une classe professionnelle dont le travail à plein temps consiste à lire ces récits et à saisir manuellement des points de données spécifiques dans d'autres systèmes. On les appelle les abstracteurs de données cliniques, et ils représentent l'un des plus grands coûts de main-d'œuvre cachés dans le système de santé américain.

Les abstracteurs de données cliniques sont généralement des infirmières diplômées (ID), des techniciens en information de santé agréés (RHIT) ou des registraires de tumeurs certifiés (CTR) — des cliniciens agréés ou des professionnels de l'information de santé certifiés qui examinent les dossiers des patients et extraient des éléments de données clés pour les rapports de qualité, les registres cliniques, la recherche et la conformité réglementaire. Le travail nécessite des connaissances cliniques : on ne peut pas abstraire un registre chirurgical sans comprendre l'anatomie opératoire, et on ne peut pas abstraire un registre cardiaque sans interpréter les données hémodynamiques. L'American Data Network, l'une des plus grandes sociétés d'externalisation d'abstraction clinique, décrit la tâche principale de l'abstracteur comme l'examen des « notes cliniques, résultats de tests, rapports d'imagerie et médicaments » et la traduction de « ces détails en champs structurés. »

L'ampleur de cette main-d'œuvre est difficile à mesurer précisément car l'abstraction n'est pas un titre de poste standardisé — elle est intégrée dans les services qualité, les équipes de registres et les unités de recherche clinique. Mais l'économie est visible au niveau de l'hôpital. Une présentation de 2018 de l'équipe des opérations de registre du Massachusetts General Hospital a décomposé les coûts de personnel pour 11 registres de sociétés de spécialités chirurgicales dans un seul centre médical universitaire :

Soit cinq registres dans un seul hôpital, représentant environ 1,2 à 1,7 million de dollars de coûts annuels de personnel — et ce ne sont que les registres pour lesquels le MGH a publiquement partagé ses données d'ETP. La plupart des centres médicaux universitaires participent à 8 à 15 registres. La base de données nationale de la Society of Thoracic Surgeons couvre à elle seule 95 % des chirurgies cardiaques adultes aux États-Unis, chaque cas de PAC nécessitant l'extraction de plus de 200 éléments de données couvrant les facteurs de risque préopératoires, les détails peropératoires et les résultats à 30 jours post-sortie. Le réseau NCDR — géré par l'American College of Cardiology — comprend plus de 2 400 hôpitaux répartis dans six registres couvrant le cathétérisme cardiaque, l'implantation de DCI, les procédures valvulaires, et plus encore.

Une enquête menée à l'été 2024 par Carta Healthcare auprès d'abstractions de données cliniques dans des hôpitaux américains a révélé que 50 % des répondants consacrent plus de la moitié de leur temps à la saisie et à l'abstraction manuelles de données. L'enquête décrit « un paradoxe troublant : alors que les cliniciens considèrent les registres comme essentiels à l'amélioration de la qualité et des processus, la tâche fastidieuse de l'abstraction manuelle des données pousse ces professionnels à leurs limites ». Interrogés sur l'automatisation, 45 % pensaient que les outils automatisés accéléreraient l'abstraction pour leur organisation, 30 % qu'ils amélioreraient la qualité des données et 20 % qu'ils réduiraient les coûts. La demande d'automatisation vient des abstractions eux-mêmes — les personnes dont les emplois, en théorie, pourraient être menacés par l'automatisation. En pratique, le volume de données à abstraire croît plus vite que la main-d'œuvre ne peut suivre.

Sur Reddit, le sentiment est plus direct. Un professionnel de la recherche clinique a posté : « Je viens de passer des heures à essayer de saisir des données de patients dans un registre pour découvrir qu'il y a près de 100 patients dans ce registre (tous en retard). » Un autre fil sur r/clinicalresearch demande, simplement : « Combien de temps consacre-t-on généralement à la saisie de données ou à la consultation des dossiers patients pour obtenir des informations ? » — le genre de question qui signale un problème de flux de travail si ancré dans les opérations quotidiennes que personne n'a de réponse de base, car la réponse est « la majeure partie de la journée ».

L'échelle économique devient visible lorsque l'on extrapole : un seul extracteur de données cliniques gagnant 75 000 $ par an et consacrant 50 % de son temps à lire un rapport, trouver une valeur spécifique et la saisir dans un autre système représente environ 37 500 $ de main-d'œuvre annuelle consacrée à de la transcription de fait. Multiplié par l'effectif d'extraction d'un seul hôpital universitaire multi-registre — 10 à 20 ETP — cela représente 375 000 à 750 000 $ par hôpital et par an. Rien que pour les 2 400 hôpitaux participants au NCDR, le coût agrégé de l'extraction manuelle des registres se situe prudemment dans la fourchette basse des milliards de dollars par an, sans tenir compte du coût d'opportunité des professionnels cliniques qualifiés qui effectuent de la transcription de données au lieu d'un travail en contact avec les patients.

Un patient, un dossier, cinq registres — et cinq sessions de saisie distinctes

L'économie de l'abstraction est multipliée par une caractéristique structurelle des registres cliniques qui n'a pas d'équivalent dans d'autres secteurs : plusieurs registres puisent dans les mêmes documents sources, mais ils ne partagent pas leurs données entre eux.

Prenons un patient subissant un pontage aorto-coronarien. La base de données de la Society of Thoracic Surgeons (STS) sur la chirurgie cardiaque adulte exige plus de 200 éléments de données pour ce patient : facteurs de risque préopératoires (diabète, fraction d'éjection, angioplastie antérieure), détails peropératoires (nombre de greffons, temps de clampage, utilisation de l'artère mammaire interne) et résultats à 30 jours (mortalité, AVC, infection sternale profonde, insuffisance rénale, ventilation prolongée).

Le même dossier patient contient le même compte rendu opératoire. Mais ce patient peut également être saisi dans le registre NCDR CathPCI — car il a eu une cathétérisme préopératoire — et ce registre possède son propre dictionnaire de données avec ses propres définitions de champs. Si l'intervention impliquait une procédure valvulaire par cathéter, le registre STS/ACC TVT ajoute un autre ensemble de variables. Si le patient a présenté une complication nécessitant un retour au bloc opératoire, le registre de qualité chirurgicale ACS NSQIP peut s'appliquer. Si l'hôpital participe à un programme Get With The Guidelines (GWTG) pour la pathologie cardiovasculaire du patient, cela constitue un cinquième registre avec ses propres exigences d'abstraction.

Les cinq registres lisent les mêmes documents sources. Le même compte rendu radiologique. Le même compte rendu opératoire. Le même résumé de sortie. Les mêmes valeurs biologiques. Et dans presque tous les hôpitaux des États-Unis, cinq flux de travail distincts de saisie de données — souvent répartis entre différents extracteurs, parfois la même personne effectuant cinq fois le même travail — extraient manuellement des données redondantes dans cinq plateformes de soumission distinctes.

Les données du MGH le montrent. Un seul hôpital gère 11 registres chirurgicaux, avec des besoins en personnel allant de 0,5 ETP (petits registres ≤500 cas/an) à 10 ETP (registre de transplantation avec 750 cas/an). Les définitions des variables diffèrent souvent d’un registre à l’autre, même pour un même concept clinique — un registre définit « insuffisance rénale postopératoire » avec un seuil de créatinine, un autre avec un seuil ou une fenêtre temporelle différente. Le temps d’extraction par cas varie de 15 minutes à 4 heures, selon la complexité du registre et l’évolution clinique du patient.

Ce n’est pas un problème d’interopérabilité technique que HL7 FHIR peut résoudre. FHIR peut normaliser le transport des données entre les systèmes — garantir que lorsque le système A envoie une valeur biologique au système B, les deux systèmes s’accordent sur le format de transmission. Ce que FHIR ne peut pas faire, c’est transformer un paragraphe narratif en champ structuré. Il ne peut pas lire un compte rendu radiologique indiquant « nodule spiculé de 1,2 cm » et remplir un champ de registre pour « taille de la tumeur dans sa plus grande dimension ». Cette transformation — de la prose aux données structurées — nécessite encore un lecteur humain, ou un système d’IA capable d’extraction sémantique. Les normes d’interopérabilité ont résolu le problème de transmission. Elles n’ont pas résolu le problème de structuration.

L’ironie : déjà numérique, mais pas structuré

Il existe un discours persistant dans l’informatique de santé selon lequel le défi est la « numérisation » — faire passer les dossiers papier dans des ordinateurs. Ce discours avait du sens en 2005, quand la plupart des hôpitaux utilisaient encore des dossiers papier et que la loi HITECH n’avait pas encore débuté. Il n’en a plus aucun aujourd’hui. Plus de 90 % des hôpitaux américains utilisent un DSE. Les services de radiologie sont sans film depuis plus d’une décennie ; la plupart des comptes rendus radiologiques sont générés, signés et distribués entièrement dans des flux de travail numériques PACS vers DSE. Les comptes rendus de sortie sont tapés, non dictés sur cassettes. Les comptes rendus opératoires sont saisis dans des modules DSE préstructurés. La documentation clinique la plus importante — les récits qui contiennent les informations cliniques les plus riches — est déjà numérique.

Le goulot d’étranglement n’est pas la numérisation. Le goulot d’étranglement, c’est la structuration.

Et ce goulot a une forme précise et mesurable. C’est l’écart entre « ce patient a eu un PAC » — un fait structuré que le DSE peut rapporter — et les 200 points de données individuels que le registre STS exige sur la façon dont ce PAC a été réalisé. Chacun de ces 200 points de données existe quelque part dans la documentation clinique : la fraction d’éjection préopératoire est dans le compte rendu d’échocardiographie, le nombre de greffons est dans le compte rendu opératoire, la durée de ventilation postopératoire est dans la feuille de réanimation, le statut de mortalité à 30 jours provient d’un appel de suivi post-sortie documenté sous forme de note libre. L’information est dans le dossier. Elle n’est simplement pas dans un format lisible par une machine.

Cela redéfinit toute la conversation sur l’automatisation. La question n’est pas « pouvons-nous numériser la documentation clinique ? » — ce navire a déjà quitté le port. La question est « pouvons-nous extraire des données structurées à partir de récits cliniques déjà numériques, sans embaucher plus de personnes pour lire et taper ? »

La distinction est importante car elle détermine le type de technologie réellement adapté au problème. La ROC basée sur des modèles — celle qui lit « où » se trouve un champ sur une page — a été conçue pour des documents à mise en page fixe : formulaires standardisés, tableaux imprimés, factures structurées. Un compte-rendu opératoire clinique n’a pas de mise en page fixe. C’est un paragraphe narratif, rédigé par un chirurgien, décrivant une procédure qui peut se dérouler différemment à chaque fois. On ne peut pas modéliser un récit. On ne peut que le comprendre.

C’est là qu’intervient la génération actuelle d’outils d’extraction par IA — construits sur des modèles de langage visuels (VLM) plutôt que sur la ROC par modèle. Un VLM n’a pas besoin de savoir où se trouve la fraction d’éjection sur la page. Il doit savoir ce qu’est une fraction d’éjection — une valeur en pourcentage, généralement exprimée comme « FE 45 % » ou « FEVG estimée à 40-45 % » — et la trouver dans le récit où qu’elle apparaisse. Il s’agit d’une extraction sémantique, et non d’une extraction par coordonnées. Elle repose sur le principe que les concepts cliniques ont des signatures sémantiques cohérentes à travers des récits formulés différemment, et qu’un modèle entraîné à comprendre le langage peut trouver « la fraction d’éjection » quel que soit le libellé utilisé par le cardiologue : « FE 40 % » ou « fonction systolique VG modérément réduite, FEVG estimée à 40-45 % ».

Ce que structurer des données cliniques signifie vraiment

Si le goulot d'étranglement est la structuration — et non la numérisation — alors la solution n'est ni un meilleur scanner ni un dactylo plus rapide. C'est un système capable de lire les récits cliniques comme le ferait un abstracteur humain : comprendre le sens de chaque phrase, identifier les concepts qui correspondent aux champs du registre, et produire une sortie structurée qu'un humain peut ensuite valider.

Il s'agit d'une tâche fondamentalement différente de celle pour laquelle la plupart des outils d'automatisation documentaire ont été conçus. Les outils d'extraction documentaire traditionnels — ceux qui traitent les factures et les bons de commande — fonctionnent en apprenant la mise en page d'un formulaire. Ils mémorisent que « Numéro de facture » apparaît en haut à droite et que « Total » apparaît en bas de la dernière page. Lorsqu'une nouvelle facture du même fournisseur arrive, l'outil lit les mêmes coordonnées et extrait les mêmes champs. Lorsqu'un fournisseur différent envoie une facture formatée différemment, l'outil a besoin d'un nouveau modèle.

Les récits cliniques déjouent cette approche sur deux fronts. Premièrement, il n'y a pas de mise en page fixe — un résumé de sortie de l'Hôpital A et un résumé de sortie de l'Hôpital B sont tous deux des récits, mais ils organisent l'information différemment, utilisent des titres différents et expriment les concepts cliniques avec un vocabulaire différent. Deuxièmement, et plus fondamentalement, les données elles-mêmes ne sont pas positionnelles. Vous ne trouverez pas « temps de clampage 47 minutes » dans une case spécifique du compte rendu opératoire. Vous le trouverez intégré dans un paragraphe, entouré d'autres détails chirurgicaux, rédigé dans le style de prose que le chirurgien préfère.

L'extraction sémantique résout ce problème en opérant sur le sens, et non sur la position. Le VLM lit l'intégralité du document, identifie les concepts cliniques présents et extrait les valeurs correspondant à chaque concept — quel que soit l'emplacement du concept sur la page, la formulation utilisée par l'auteur, ou le type de document (PDF tapé, rapport scanné, capture d'écran de l'interface du DSE). L'extracteur n'a pas besoin d'être réentraîné pour chaque nouveau format de documentation hospitalière, car il n'apprend pas des formats — il reconnaît des concepts.

Le flux de travail pratique n'est pas « l'IA remplace l'abstracteur ». Il est « l'IA gère l'étape de lecture, et l'abstracteur gère l'étape de validation ». L'IA remplit les 200+ champs du registre cardiaque STS à partir du compte rendu opératoire, du résumé de sortie, du rapport d'échographie et de la note de suivi. L'abstracteur — un infirmier diplômé avec une expérience en chirurgie cardiaque — vérifie les champs remplis, corrige les éventuelles erreurs d'extraction, applique son jugement clinique aux cas ambigus et soumet l'entrée validée. Le temps de l'abstracteur passe de la recherche des données (parcourir 80 pages de documentation du DSE, la partie qui consomme 50 %+ de la journée de travail selon l'enquête Carta) à la validation des données (la partie qui nécessite une expertise clinique et ne peut être automatisée).

Pour un patient CABG dont l'abstraction prend actuellement 45 à 90 minutes — couvrant la documentation préopératoire, peropératoire et postopératoire dans plusieurs modules du DME — un outil d'extraction sémantique qui gère la collecte initiale des données peut réduire de moitié, voire plus, le temps par cas pour l'abstraction. Le calcul est simple : si une infirmière abstractionniste gagnant 40 $/heure traite 1 300 cas CABG par an (le volume rapporté par MGH pour leur registre STS-Cardiac), et que l'extraction assistée par IA économise 30 minutes par cas, cela représente 650 heures de travail infirmier récupérées par an — soit environ 26 000 $ de coût salarial réaffecté, de la transcription vers la validation et l'amélioration de la qualité. Sur cinq registres, dans 2 400 hôpitaux, le total n'est pas une erreur d'arrondi.

Questions fréquentes

Pourquoi les DSE ne rendent-ils pas la documentation clinique structurée par défaut ?

Parce que la saisie structurée — menus déroulants, cases à cocher, vocabulaires contraints — est fondamentalement incompatible avec la façon dont les cliniciens pensent et communiquent. Une case à cocher peut capturer « douleur thoracique : présente », mais ne peut pas capturer « patient décrit une pression thoracique sous-sternale intermittente irradiant vers l'épaule gauche, aggravée par l'effort, soulagée par le repos, début il y a environ 2 semaines, fréquence croissante ». La case à cocher capture un code de facturation. Le récit capture le raisonnement clinique. Forcer les cliniciens à documenter exclusivement dans des champs structurés produirait des données lisibles par les machines mais inutilisables par les autres cliniciens. Le compromis est réel, et la communauté médicale a — à juste titre — opté pour une documentation cliniquement utile plutôt qu'une documentation adaptée aux machines.

À combien de registres cliniques un hôpital typique participe-t-il ?

Un hôpital communautaire peut participer à 3 à 5 registres — généralement pour l'AVC (GWTG), les procédures cardiaques (NCDR CathPCI) et la qualité chirurgicale (ACS NSQIP). Un grand centre médical universitaire participe généralement à 10 à 15 registres, couvrant la chirurgie cardiaque (STS), les traumatismes (TQIP), les transplantations (SRTR), l'oncologie (NCDB) et de multiples registres de sous-spécialités. Les données publiées du MGH couvrent 11 registres ; de nombreux centres universitaires dépassent ce nombre. Chaque registre ajoute des ETP d'abstraction, et les ETP se cumulent car les registres ne partagent pas les données.

Quels types de documents cliniques nécessitent une abstraction manuelle ?

Les documents qui génèrent le plus de travail d'abstraction sont les comptes rendus de radiologie, les résumés de sortie, les notes opératoires, les notes d'évolution et les comptes rendus d'anatomopathologie — des documents très narratifs où se trouve l'information clinique la plus riche. Les valeurs de laboratoire, les prescriptions médicamenteuses et les signes vitaux sont des données structurées que les DSE peuvent exporter directement. Le travail manuel se concentre massivement sur les documents en texte libre qui contiennent le raisonnement clinique et les nuances que les champs structurés n'ont jamais été conçus pour capturer.

L’IA peut-elle lire un compte rendu radiologique avec assez de précision pour un usage dans un registre ?

Les modèles de langage visuels peuvent extraire des données discrètes des comptes rendus radiologiques — dimensions tumorales, latéralité, modalité d’imagerie, recommandations de suivi — avec une précision qui les rend viables comme outil de premier passage pour validation par un abstracteur. Ils ne remplacent pas la relecture clinique, car les comptes rendus radiologiques contiennent des ambiguïtés (impressions prudentes, mesures qualifiées d’« approximatives ») qui nécessitent une interprétation humaine. L’architecture appropriée est l’abstraction assistée par IA : le modèle remplit les champs, l’abstracteur valide. C’est le même modèle que l’enquête Carta a montré que les abstracteurs souhaitaient — des outils qui réduisent le temps de recherche manuelle sans remplacer le jugement clinique.

Quelle est la différence entre numérisation et structuration dans la documentation clinique ?

La numérisation consiste à convertir un document du format physique au format électronique — scanner un dossier papier, générer un PDF à partir d'un DSE, stocker une image dans un PACS. Le document devient un fichier. La structuration consiste à convertir le contenu de ce document d'un récit narratif en champs de données discrets et interrogeables — extraire « temps de clampage : 47 minutes » d'un paragraphe dans un compte rendu opératoire et remplir un champ de base de données appelé « temps_clampage_minutes » avec la valeur « 47 ». La numérisation crée un fichier qu'un humain peut lire. La structuration crée des données qu'une machine peut utiliser. Le problème dans la documentation clinique est que la numérisation a eu lieu, mais que la structuration n'a pas suivi — c'est pourquoi les hôpitaux emploient encore des personnes pour le faire manuellement.