Développement et validation d’un algorithme de prédiction de la sévérité (score NIHSS) des AVC ischémiques (code CIM-10 « I63_ ») hospitalisés
Lien vers le repo : Gitlab
Objectifs de l’algorithme
L’algorithme « ALIA1 – NIHSS dans le SNDS » vise à produire, pour tout AVC ischémique hospitalisé, une estimation de la sévérité de l’AVC. Il n’a pas vocation à être utilisé à l’échelle individuelle : il est employé pour dresser une cartographie à l’échelle nationale des AVC ischémiques, leur nombre, le département et l’année de survenue, la mortalité associée ainsi qu’un NIHSS estimé.
Auteur(s)
Domaine médical
Méthodologie
Contexte de création :
Il a été employé début 2024 par le Département des Maladies Non-Transmissibles et Traumatismes (DMNTT) de Santé publique France (SpF), afin de dresser une cartographie couvrant la France (hors DROM) de 2012 à 2019, pour tout·e bénéficiaire âgé.e d’au moins 16 ans. Il n’a pas vocation à être réemployé dans l’immédiat, mais une mise à jour de la cartographie pourrait être opérée à l’avenir lorsque les données du SNDS et du registre des AVC du Pays de Brest seront consolidées pour des années plus récentes. Au cours du développement de cet algorithme, de nombreuses fonctions (R) ont été développées pour faciliter la manipulation du SNDS, établir des résumés de séjours hospitaliers, etc. et sont rendues disponibles en même temps.
Méthodologie :
Les observations d’intérêts sont les AVC ischémiques hospitalisés. Ceux-ci sont identifiés sur la base d’un code CIM-10 commençant par I63 dans les bases de données du PMSI MCO (tables A, D, UM). Le séjour est reconstitué en agrégeant les informations d’autres séjours du PMSI identifiés comme survenant à moins d’un mois de distance après le séjour pour AVC. Le séjour hospitalisé est caractérisé par (a) tout diagnostic concomitant, (b) tout acte et/ou prestation concomitante au séjour ou survenant jusque 10 jours après celui-ci, (c) diverses informations concernant le/la bénéficiaire (âge, sexe, mode de sortie du séjour, date de décès etc.).
Sur la base de ces séjours qualifiés, une probabilité de décès à 10 jours est calculée en mettant en concurrence plusieurs approches (régression logistique multivariée avec ou sans LASSO, Random Forest), stratifiée à l’échelle départementale. Cette probabilité de décès a été convertie en NIHSS estimé, grâce à l’exploitation des données du registre des AVC du Pays de Brest, dans lequel le NIHSS et le statut vital à 10 jours sont accessibles, et ont été mis en équation.
Une évaluation externe des performances de l’algorithme a été permise par l’exploitation du registre des AVC de la ville de Dijon, en comparant les prévalences d’AVC ayant un NIHSS <5, 5–20, ou >20, prédites par l’algorithme, et celles connues grâce au registre. Cet algorithme devrait faire l’objet d’une publication future, en cours de rédaction.
Langage de programmation
Données utilisées
Données d'application
Ont servi au développement et à la validation de l’algorithme :
- Le registre des AVC du Pays de Brest, afin d’établir une mise en équation de la sévérité des AVC (score NIHSS) avec la mortalité à 10 jours.
- Les données du SNDS, afin d’établir une cartographie des AVC ischémiques et de leur sévérité estimée. En particulier, sont exploitées les tables T_MCOaaA, T_MCOaaB, T_MCOaaC, T_MCOaaD, T_MCOaaUM, T_MCOaaMEDTHROMBO, T_MCOaaCSTC, T_MCOaaFBSTC, T_MCOaaFMSTC, IR_BEN_R, IR_IMB_R, et ER_CAM_F.
- Le registre des AVC de la ville de Dijon, afin de procéder à une évaluation externe des prédictions de l’algorithme.
Validation
Ces tableaux de performances seront disponibles dans la publication scientifique détaillant le développement et la validation de l’algorithme :
Validation « interne » dans le périmètre couvert par le registre des AVC du Pays de Brest
Validation externe dans le périmètre couvert par le registre des AVC de la ville de Dijon
NB1. Les résultats présentés sont ceux obtenus avec une probabilité de décès à 10 jours calculée par régression logistique multivariée, et une mise en équation NIHSS – probabilité de décès établie sur le registre des AVC du Pays de Brest passant par un modèle en régression polynomiale.
NB2. Du fait du grand nombre d’observations, les tests d’égalité entre les prévalences prédites et observées ne sont pas considérés comme critiques pour évaluer la performance de l’algorithme. À la place, un modèle a été considéré pertinent s’il répondait aux critères suivants : ratio des prévalences compris entre 0.85 et 1.15, et test d’équivalence (Two Onde-Sided t-Tests « TOST ») avec une p-value inférieure à 0.05 (i.e. intervalle de confiance de la différence entre les prévalences comprises à l’intérieur de l’intervalle [-5% – +5%]).
Date de dernière mise à jour
Il s’agit de la version 1.0, publiée le 17 avril 2024.
Maintenance
L’algorithme ne sera vraisemblablement pas maintenu :
- Son usage n’a pas vocation à être réitéré régulièrement, une fois la cartographie établie.
- Son auteur principal n’est plus en contrat à Santé publique France, et aucune garantie ne peut être apportée quant à ses futures missions et au temps qu’il pourra y accorder.
Comment installer l’algorithme ?
Pour être en mesure de lancer les algorithmes sur le portail de la CNAM, il convient de reproduire l’architecture du dossier « ALIA1 – NIHSS dans le SNDS » disponible sur ce repo. Le dossier doit être placé dans sasdata1 (ou un sous-dossier de sasdata1), et son architecture ainsi que son contenu doivent être inchangés afin que les fonctions puissent être appelées correctement.
Comment utiliser l’algorithme ?
Le sous-dossier « script » contient les scripts suivant :
- ALIA1_1_ExtractionCohortesDeDerivation.R, permettant d’établir des cohortes de dérivations sur lesquelles seront développés les premiers modèles.
- ALIA1_2_PredictionStatutVital.R, mettant en concurrence plusieurs algorithmes de Machine Learning visant à établir une probabilité de mortalité à 10 jours de chaque AVC.
- ALIA1_3_CartographieNIHSS.R, procédant à la cartographie des AVC en France (hors DROM) selon plusieurs approches mises en compétition.
Ces trois scripts doivent être lancés dans l’ordre (comptez quelques heures à une nuit de travail pour chaque script).
Le sous-dossier « reports » contient un rapport qui peut être lancé après les trois scripts mentionnés plus haut afin de produire un rapport au format .html résumant de nombreuses information sur la population d’étude et les performances de l’algorithme.
Support
Crédits
Nicolas MINIER : https://gitlab.com/NicolasMINIER
Licence et conditions d’utilisation
Apache 2.0