Améliorer l'interopérabilité des données de santé avec de grands modèles linguistiques : une étude FHIR

Tableau des liens

Introduction

Méthodes

Résultats et discussions

Conclusion et références

Introduction

L’intégration et l’échange de données de santé sur diverses plateformes et systèmes restent difficiles en raison de l’absence de formats standardisés et d’une compréhension sémantique partagée. Ce défi devient encore plus important lorsque les informations critiques sur la santé sont intégrées dans des données non structurées plutôt que dans des formats structurés bien organisés. La normalisation des données de santé non structurées, telles que les notes cliniques, dans les ressources FHIR peut atténuer l'ambiguïté entre les différents prestataires de santé et, par conséquent, améliorer l'interopérabilité. Toutefois, ce n’est en aucun cas une tâche facile. Des études antérieures 1,2 ont tenté de transformer des notes cliniques en ressources FHIR en utilisant une combinaison d'outils de traitement du langage naturel et d'apprentissage automatique via des processus en plusieurs étapes impliquant la reconnaissance d'entités nommées cliniques, le codage terminologique, les calculs mathématiques, le formatage structurel et les étalonnages humains. Cependant, ces approches nécessitent un effort humain supplémentaire pour consolider les résultats de plusieurs outils et n’ont atteint que des performances modérées, avec des scores F1 allant de 0,7 à 0,9 dans différents éléments. À cette fin, nous avons l'intention d'exploiter les grands modèles linguistiques (LLM) pour générer directement des ressources au format FHIR à partir de la saisie de texte libre. L'utilisation des LLM devrait simplifier les processus auparavant en plusieurs étapes, améliorer l'efficacité et la précision de la génération automatique de ressources FHIR et, à terme, améliorer l'interopérabilité des données de santé.

Méthodes

Annotation des données À notre connaissance, il n'existe pas d'ensemble de données largement accessible au public dans la norme FHIR qui soit généré à partir de données contextuelles. Par conséquent, nous avons choisi d'annoter un ensemble de données contenant à la fois une entrée en texte libre et une sortie structurée aux formats FHIR. L'entrée en texte libre a été dérivée des résumés de décharge de la base de données MIMICIII. 3 Grâce au challenge d'extraction de médicaments n2c2 2018 4 , qui concerne essentiellement des tâches de reconnaissance d'entités nommées, des éléments dans les déclarations de médicaments ont été identifiés. Nos annotations se sont appuyées sur ces annotations n2c2 et ont standardisé le texte libre dans plusieurs systèmes de codage de terminologie clinique, tels que NDC, RxNorm et SNOMED. Nous avons organisé les contextes et les codes en ressources FHIR medicineStatement. Les ressources FHIR converties ont été validées par le validateur officiel FHIR (https://validator.fhir.org/) pour garantir la conformité aux normes FHIR, notamment la structure, le type de données, les jeux de codes, les noms d'affichage, etc. Ces résultats validés ont été considérés comme les résultats de transformation de référence et pourraient être utilisés pour tester par rapport aux LLM. Il n'existe aucune préoccupation éthique concernant l'utilisation des données, car les ensembles de données MIMIC et n2c2 sont accessibles au public pour les utilisateurs autorisés.

Modèle de langage étendu Nous avons utilisé le modèle GPT-4 d'OpenAI comme LLM pour la transformation du format FHIR. Nous avons utilisé cinq invites distinctes pour demander au LLM de transformer le texte libre saisi en médicament (y compris le code du médicament, la concentration et la forme), l'itinéraire, le calendrier, la posologie et la raison, respectivement. Toutes les invites adhéraient à un modèle avec la structure suivante : instructions de tâche, modèles FHIR de sortie attendus au format .JSON, 4 à 5 exemples de conversion, une liste complète de codes à partir desquels le modèle peut effectuer des sélections, puis le texte d'entrée. Comme il n'y avait pas de réglage fin ou d'adaptation spécifique à un domaine dans nos expériences, nous avons initialement demandé au LLM de générer un petit sous-ensemble (N = 100). Ensuite, nous avons examiné manuellement les écarts entre la sortie FHIR générée par LLM et nos annotations humaines. Les erreurs courantes ont été identifiées et utilisées pour affiner les invites. Il est important de noter que nous n'avons pas eu accès à toutes les listes de codes de médicaments NDC, RxNorm et SNOMED pour les noms de médicaments, ainsi qu'aux codes de recherche SNOMED pour des raisons. De plus, même si nous avions des listes aussi complètes, elles auraient dépassé les limites de jetons pour les LLM. Ainsi, nous n’avons pas chargé les LLM de coder ces entités ; au lieu de cela, nous leur avons demandé d'identifier les contextes mentionnés dans le texte d'entrée. Pour d'autres éléments, par exemple les itinéraires et les formes de drogues, qui se comptent par centaines, nous avons permis aux LLM de les coder directement. Lors de l'évaluation des résultats générés par LLM, notre principal critère était le taux de correspondance exact, ce qui nécessite un alignement précis avec les annotations humaines dans tous les aspects, y compris les codes, les structures, etc. De plus, nous avons signalé les scores de précision, de rappel et de F1 pour des occurrences d'éléments spécifiques. Nous avons accédé aux API GPT-4 via le service Azure OpenAI, conformément aux directives d'utilisation responsable des données MIMIC. Le modèle spécifique que nous avons utilisé était « gpt-4-32k » dans sa version « 2023-05-15 ». Chaque saisie de texte a été transformée individuellement en une ressource MedicationStatement. Pour optimiser l'efficacité, nous avons effectué plusieurs appels API asynchrones.

Résultats et discussions

Les résultats de l'annotation et de la génération FHIR sont présentés dans le tableau 1. En résumé, nous avons annoté 3 671 ressources sur les médicaments, couvrant plus de 625 médicaments distincts et associés à 354 raisons. Le Large Language Model (LLM) a atteint un taux de précision impressionnant de plus de 90 % et un score F1 supérieur à 0,96 pour tous les éléments. Dans des études antérieures, les scores F1 atteignaient 0,750 en timing.repeat, 0,878 en timing.route et 0,899 en timing dosage. 1 Le LLM a amélioré ces scores F1 d'au moins 8 %. Il convient de noter que les études précédentes utilisaient un ensemble de données privées plus petit, n'employaient pas les mesures d'évaluation les plus strictes telles que le taux de correspondance exact, ignoraient le codage terminologique et nécessitaient une formation approfondie. Après une enquête plus approfondie, nous avons également été impressionnés par la grande précision du codage terminologique (qui implique essentiellement une tâche de classification avec plus de 100 classes), de la conversion mathématique (par exemple, déduire une durée de 10 jours lorsque l'entrée mentionne « TID, distribuer 30 comprimés). '), la conformité du format (avec moins de 0,3 % de chances que les résultats ne puissent pas être interprétés au format .JSON) et la cardinalité (le LLM peut gérer à la fois les relations 1:N et 1:1).

La précision du résultat dépend fortement des invites d’instructions utilisées. Sur la base de nos nombreux essais et erreurs, nous avons les recommandations suivantes : i) fournir divers exemples de conversion qui englobent un large éventail de cas extrêmes hétérogènes ; ii) utiliser un langage fort, tel que « DOIT », pour garantir que le résultat respecte les formats et les règles attendus ; iii) mettre à jour et affiner continuellement les invites en examinant les résultats d'un petit sous-ensemble, ce qui peut aider à identifier les erreurs courantes et à améliorer la précision globale ; iv) soyez prudent avec les codages hors vocabulaire. Les LLM peuvent tenter de répondre aux besoins des utilisateurs en inventant des codes qui n'existent pas lorsqu'ils ne trouvent pas de correspondance étroite.

Conclusion

Dans cette étude, nous avons jeté les bases de l’exploitation des LLM pour améliorer l’interopérabilité des données de santé en transformant la saisie de texte libre en ressources FHIR. Les études futures viseront à s'appuyer sur ces succès en étendant la génération à des ressources FHIR supplémentaires et en comparant les performances de différents modèles LLM.

Référence

1. Hong N, Wen A, Shen F, Sohn S, Liu S, Liu H, Jiang G. Intégration de données DSE structurées et non structurées à l'aide d'un système de type FHIR : une étude de cas avec des données sur les médicaments. Sommets AMIA sur les actes de la science translationnelle. 2018 ; 2018 : 74.

2. Hong N, Wen A, Shen F, Sohn S, Wang C, Liu H, Jiang G. Développement d'un pipeline évolutif de normalisation des données cliniques basé sur FHIR pour normaliser et intégrer les données des dossiers de santé électroniques non structurés et structurés. JAMIA ouvert. Décembre 2019;2(4):570-9.

3. Johnson AE, Pollard TJ, Shen L, Lehman LW, Feng M, Ghassemi M, Moody B, Szolovits P, Anthony Celi L, Mark RG. MIMIC-III, une base de données de soins intensifs accessible gratuitement. Données scientifiques. 24 mai 2016;3(1):1-9.

4. Henry S, Buchan K, Filannino M, Stubbs A, Uzuner O. 2018 n2c2 ont partagé la tâche sur les événements indésirables liés aux médicaments et l'extraction de médicaments dans les dossiers de santé électroniques. Journal de l'American Medical Informatics Association. 2020 janvier ;27(1):3-12.