Version imprimable multipages. Cliquer ici pour imprimer.
News
- Datathon InterHop 2024 - CIM-10 LLM
- Datathon InterHop 2024 - Fractures de fémur
- Datathon InterHop 2024 - Indicateurs d'activité de maternité
- Datathon InterHop 2024 - Qualité des données
- Datathon InterHop 2024 - Prédiction de la mortalité
- Datathon InterHop 2024 - FINESS+
- Datathon InterHop 2024 - Sujets
Datathon InterHop 2024 - CIM-10 LLM
Introduction
A chaque séjour hospitalier d’un patient, des codes CIM-10 sont attribués, correspondant aux pathologies présentées durant le séjour.
La base de données CIM-10 est complexe, et il est parfois difficile de trouver les diagnostics que nous recherchons. Les requêteurs “classiques” que nous trouvons sur internet utilisent des outils de recherche classique (à base de regex) non optimaux.
Les LLM (Large Language Models, tels que ChatGPT pour le plus connu), grâce au RAG (retrieval augmentated generation) permettent d’utiliser les LLM en les “nourrissant” de fichiers, tels qu’un fichier CSV contenant l’ensemble des diagnostics.
Ainsi, il est possible d’utiliser un LLM déjà entraîné, de lui fournir la base de données CIM-10 et de l’interroger directement pour nous donner les codes demandés.
L’approche par RAG a l’avantage de diminuer le risque d’hallucinations.
Matériel et méthodes
La base de données CIM-10 est disponible au format OMOP sur le site Athena.
Des LLM seront utilisés (soit accessibles via API tels que GPT-4, soit téléchargés localement tels que Llama 7B). La base de données CIM-10 alimentera un RAG.
Le choix des librairies utilisées est libre. Voici quelques propositions :
- Transformers, lien vers les fonctions RAG
- LangChain : lien vers les fonctions RAG
- LlamaIndex : lien vers les fonctions RAG
La recherche s’effectuera à l’aide d’une interface graphique, sous la forme d’une application web.
En bonus, nous pouvons également imaginer :
- un système de favoris, où les diagnostics les plus fréquemment choisis par l’utilisateur seront mis en avant
- un système de recherche classique associé : l’utilisateur pourra choisir entre une recherche par regex ou une recherche par LLM (il ne faut probablement pas mettre de côté les systèmes les plus simples qui fonctionnent à moindre coût, et qui malgré tout répondent à la demande dans la majorité des cas)
- une système speech to text, pour transformer la requête audio en prompt
Conclusion
L’intégration de LLM avec la méthode RAG pour la recherche de codes CIM-10 pourrait permettre une recherche plus facile et plus précise qu’avec les systèmes de recherche classique.
Datathon InterHop 2024 - Fractures de fémur
Avec ce sujet les participant⸱es ambitionnent d’implémenter un module de statistiques prêt à l’emploi au sein de l’outil opensource logiciel LinkR
Introduction
La fracture de l’extrémité supérieure du fémur est un pathologie fréquente (> 75 000 cas par an en France), touchant une population âgée. Elle est à l’origine d’une mortalité, d’une morbidité et d’une perte d’autonomie importantes entraînant un coût important. Son incidence est en augmentation du fait d’un vieillissement de la population. Tout ceci en fait un problème majeur de santé publique.
La prévalence des patients sous traitement anticoagulant est importante dans cette population gériatrique. On constate depuis 2012 et la mise sur le marché des « nouveaux » anticoagulants oraux, une forte augmentation des patients traités par ces médicaments qui remplacent les classiques AVK.
De nombreuses études ont maintenant prouvé l’importance d’une chirurgie précoce (< 48h) pour réduire la morbi-mortalité de ces fractures. Cependant la présence d’un traitement anticoagulant pourrait allonger les délais de prise en charge et augmenter la morbi-mortalité.
Afin d’uniformiser la prise en charge de ces patients et de réduire les délais de prise en charge un protocole de service a été mis en place au CH de Saint-Malo en janvier 2023.
L’objectif principal est l’évaluation de la mise en place de ce protocole. L’hypothèse formulée est que la mise en place d’un protocole permettrait d’opérer les patients plus rapidement (dans un délai inférieur à 48h).
Matériel et méthodes
Nous réalisons une étude de cohorte rétrospective, observationnelle, monocentrique.
Le critère de jugement principal est le délai de prise en charge au bloc opératoire après l’admission des patients.
Les critères de jugements secondaires sont :
- la mortalité à 30 jours
- la mortalité à un an
- les complications hémorragiques (transfusion, saignement peropératoire, variation du taux hémoglobine pré-opératoire)
Les patients seront séparés en 3 groupes :
| A | B | C |
|---|---|---|
| Patients traités par AOD opérés avant la mise en place du protocole (avant 01/2023) | Patients traité par AOD opérés après la mise en place du protocole (à partir de 01/2023) | Patients contrôles non anticoagulés opérés sur la même période |
Une première analyse statistique descriptive sera réalisée.
Les données quantitatives sont exprimées par une moyenne et un écart-type. Les données qualitatives sont exprimées en nombre et pourcentage.
Pour le critère de jugement principal nous comparerons le délai de prise en charge au bloc (exprimé en heures) entre les 3 groupes. Nous pourrons également comparer la proportion de patients opérés dans les 48 premières heures suivant leur admission. S’agissant d’une variable quantitative*nous utiliserons un t-test de Student ou un test de Kruskal-Wallis.
Pour les critères de jugement secondaires, les variables quantitatives seront comparées avec le même test et les variables qualitatives à l’aide d’un test du Chi-2.
Une analyse de survie selon Kaplan-Mayer sera réalisé pour la mortalité à 30 jours et à 1 an. Une comparaison des courbes de survie à l’aide d’un test du Log Rank sera ensuite réalisée.
Le jeu de données utilisé est un jeu de données fictif, qui sera transformé au format OMOP.
Le datathon vise à implémenter un module de statistiques au sein de l’outil open source LinkR (survie, tests paramétriques et non paramétriques).
Les résultats seront présentés sous forme de graphiques.
Ce module de statistique sera open source et pourra donc être réutilisé par l’ensemble des utilisateurs.trices de LinkR.
Le code source produit lors de ce datathon sera colligé sur le dépot de code de l’association InterHop. Il sera disponible à cette adresse.
Conclusion
Ce projet s’inscrit dans une démarche de science ouverte, où la production de code, les méthodes et les outils développés seront rendus accessibles à tous et toutes.
Avec ce sujet les participant.es ambitionnent de développer des outils et des méthodologies réutilisables par d’autres acteurs du système de santé.
Datathon InterHop 2024 - Indicateurs d'activité de maternité
Avec ce sujet les participant⸱es ambitionnent non seulement de créer des indicateurs robustes pour les maternités, mais aussi de développer des outils et des méthodologies réutilisables par d’autres acteurs du système de santé.
Introduction
Les maternités en France fournissent annuellement des indicateurs d’activité essentiels, tels que le nombre de césariennes, de sièges, de transferts, ou encore le nombre de péridurales.
Voici un exemple de ces indicateurs pour l’année 2023 dans une maternité française.
Ces indicateurs, cruciaux pour évaluer et améliorer les pratiques obstétricales, sont dérivés des séjours RSS (Résumé de Sortie Standardisé), qui reprennent les informations médicales de chaque patient lors de leur séjour hospitalier produites à travers plusieurs unités de soins.
Le challenge de ce sujet réside non seulement dans la création automatisée de ces indicateurs à partir des données brutes, mais aussi dans leur visualisation efficace.
Matériel et méthodes
Le datathon organisé par l’association InterHop.org vise à explorer ces aspects en utilisant l’outil open-source LinkR, une plateforme permettant la manipulation et l’analyse des données de santé, tant pour les cliniciens que pour les data scientists.
Pour atteindre les objectifs de ce datathon, plusieurs outils et librairies R et Python seront employés pour transformer, analyser et visualiser les données RSS.
- Création des indicateurs (à partir du format RSS) :
- R : La librairie
dplyroupmeasyrpourra être utilisée pour manipuler les données, effectuer des filtrages et des agrégations nécessaires pour restructurer les RSS - Python : Les librairies
pandas,pola.rsoupypmsiseront essentiels pour les opérations de manipulation des DataFrames, permettant de réorganiser les données et de les formater correctement pour l’analytique.
- R : La librairie
- Transformation des données vers modèle OMOP :
- Objectif subsidiaire
- ETL (Extract, Transform, Load) : les outils comme
Airflowpeuvent être intégrés pour orchestrer les pipelines de transformation des données, en automatisant le processus de conversion des RSS vers OMOP.
- Visualisation des données :
- R :
ggplot2pourra être utilisé pour créer des graphiques clairs et esthétiques des indicateurs, tels que des histogrammes des taux de césariennes, ou des courbes de survie. - Python :
matplotlibetseabornpourront être employés pour des visualisations dynamiques, etplotlypour créer des graphiques interactifs permettant aux utilisateurs de naviguer à travers les données.
- R :
- Création d’un programme de création de données synthétique au format RSS
- Objectif subsidiaire
- Données synthétiques : création d’un programme de génération de données fictives au format “RSS groupé. Les fonctions de groupement des GHM pourront aussi être implémentées à partir des guides officiels
- Pseudonymisation : création d’un programme permettant de pseudonymiser facilement un fichier au format “RSS groupé”
Les données seront issues d’un jeu de données fictif et pseudonymisé, mis à disposition des participants.
Le datathon vise à implémenter le calcul d’indicateurs clés concernant les activités des maternités françaises, accessibles et interprétables par les cliniciens, tout en fournissant une base solide pour d’autres analyses secondaires.
Cette connaissance métier sera apportée par un médecin responsable d’un Département d’Informatique Médical DIM d’un hôpital français.
Pour exemple l’Agence technique de l’information sur l’hospitalisation (ATIH) met à disposition des indicateurs sur l’activité hospitalière en périnatalité produits à partir des données PMSI (Programme de médicalisation des systèmes d’informations).
Un tableau de bord est disponible sur le site internet ScanSanté, et permet de sélectionner aussi bien le type d’indicateur que la période ou le périmètre géographique.
Les résultats seront présentés sous forme de tableaux de bord dynamiques, permettant de visualiser et d’explorer les indicateurs sur plusieurs dimensions (temps, localisation, niveau de maternité, etc).
Voici un exemple de dashboard réalisé par le NHS en Angleterre:
Avec ce datathon nous souhaitons proposer :
- une amélioration du pilotage de l’obstétrique aux différentes échelles (CHU, bassin de soin, région…), notamment à terme avec des visualisations de données historisées et des tendances, couplée à des alertes et des seuils,
- faire ressortir des nouvelles clés de compréhension et d’analyse de la MCO notamment pour les parcours MCO complexes
L’utilisation de LinkR devrait faciliter la réutilisation de ces indicateurs au sein des services des Département d’Informatique Médical (DIM) améliorant ainsi la qualité des soins obstétricaux. Nous souhaitons aussi démocratiser l’utilisation des données et permettre une utilisation plus large auprès des équipes soignantes.
Voici un exemple de rendu de tableau de bord sur LinkR :
Le code source produit lors de ce datathon sera colligé sur le dépot de code de l’association InterHop. Il sera disponible à cette adresse.
Conclusion
Ce projet s’inscrit dans une démarche de science ouverte, où la production de code, les méthodes et les outils développés seront rendus accessibles à tous et toutes.
Avec ce sujet les participant⸱es ambitionnent non seulement de créer des indicateurs robustes pour les maternités, mais aussi de développer des outils et des méthodologies réutilisables par d’autres acteurs du système de santé.
Datathon InterHop 2024 - Qualité des données
Avec ce sujet les participant⸱es ambitionnent de créer des indicateurs de qualité robustes et réutilisables. Ils pourront être intégrés au sein d’un module LinkR dédié
Introduction
La qualité des données produites dans le cadre du soin dépend-elle du logiciel qui les a générées ? Les logiciels ont-ils des biais semblables ? Certains logiciels protègent-ils mieux certaines données ? Quelle serait l’origine des erreurs ? Quelles corrections seraient applicables ?
Nous aurons 48h pour pour construire des outils qui nous permettrait de répondre à ces questions.
Matériel et méthodes
Pour faciliter ce parcours et éliminer d’emblée l’un des biais, nous travaillerons sur des données au format OMOP de la base de données MIMIC.
Pour faciliter le partage des outils et des observations, le développement sera proposé sur la plate-forme LinkR.
Les différences de comportement des logiciels seront observées selon les valeurs aberrantes que peuvent prendre les variables telles que :
- poids, taille, age, sexe
- durée de séjour dans le service
- durée d’anesthésie (selon disponibilité des données)
- doses de drogues
- proportion d’artéfacts de la pression artérielle
Des propositions de tests et de représentation sont donnés à titre de rampe de lancement.
Cette liste pourra être étendue par d’autres données, susceptibles de défaut de qualité dépendant du logiciel et si possible ayant un impact sur la prise en charge.
Les critères de vraissemblance des données pourront être simples (bornes min-max), multivariés ou utilisant des similarités. Les critères de qualités déjà définis par OMOP CDM seront utilisables.
Sélection de variables OMOP utilisables :
| measurement_source_value | measurement_concept_id | measurement_type_concept_id |
|---|---|---|
| poids | 1003901 | 32817 |
| taille | 45876161 | 32817 |
| Temp | 4302666 | 32817 |
| SpO2 | 45770406 | 32817 |
| PASd | 44782659 | 32817 |
| PASm | 4239021 | 32817 |
| PASs | 4152194 | 32817 |
| PNId | 4068414 | 32817 |
| PNIm | 4108289 | 32817 |
| PNIs | 4354252 | 32817 |
| B.I.S | 4134573 | 32817 |
| BIS signal quality index | 4134573 | 32817 |
| BIS SR | 21490690 | 32817 |
| FC | 4239408 | 32817 |
| FR | 4313591 | 32817 |
Datathon InterHop 2024 - Prédiction de la mortalité
Introduction
A l’heure actuelle, la majorité des études comparent la mortalité de groupes de patient à l’aide de scores de gravité tels que l’IGS-2 (très ancien) et le SOFA (plus récent).
L’apport du machine learning permet d’avoir des modèles de prédiction de mortalité avec de meilleures performances, ce qui a déjà été démontré dans de nombreuses études.
Ce sujet n’a donc rien de nouveau. Cependant, il n’y a pas à l’heure actuel de code OMOP partagé permettant d’appliquer ce modèle sur des données locales.
De plus, la validité externe des modèles peut poser problème : peut-être qu’entraîner les modèles localement, pour être appliqués localement, est une solution pour limiter ce problème de validité externe.
L’idée est donc ici de recréer cette étude de façon totalement interopérable, à la fois en utilisant le modèle de données OMOP et en créant ce projet sur la plateforme LinkR, qui facilite le partage des projets.
Ainsi, il sera plus facile d’entraîner ces algorithmes sur des données locales, en ayant un code interopérable.
Matériel et méthodes
Le set de données utilisé sera la base de données MIMIC OMOP.
L’outcome est la mortalité des patients admis en réanimation.
Les paramètres utilisés pour les modèles de prédiction seront les variables utilisées dans les scores SOFA et IGS-2, récupérés durant les 24 premières heures suivant l’admission en réanimation.
Les algorithmes utilisés seront :
- Régression logistique
- Random forest
- XGB
- Support vector machine
- Réseaux de neurones
Les résultats seront comparés aux prédictions données par les scores SOFA et IGS-2.
Conclusion
Développer des modèles de prédiction de la mortalité avec un code interopérable permettrait d’entraîner ces algorithmes localement dans différents centres plus facilement.
Datathon InterHop 2024 - FINESS+
Créer un référentiel FINESS amélioré aligné sur le Référentiel National du Batiment
Introduction
La santé prend le virage des parcours coordonnés de soin. Cette ambition nécessite d’avoir des données concernant l’offre de soin qui soient à jour.
Il s’agit, à terme, de tenir à jour les données géographiques élémentaires (géolocalisation des 100 000 établissements de soins recensés au FINESS) dans des systèmes ouverts comme OpenStreetMap (OSM) de sorte que ces informations restent exactes et interopérables (tags et iconographies documentés et à jour).
Ce maintien à jour pourra être fait (au moins en partie) au sein de l’association Toobib.org et de sa plateforme éponyme.
Le datathon de Rennes est l’occasion de créer un référentiel FINESS amélioré aligné sur le Référentiel National du Batiment (RNB).
Un tel alignement doit permettre:
- d’identifier des problèmes de qualité dans le FINESS sur les champs adresses ou sur les champs de géolocalisations
- de proposer des corrections sur les champs adresses ou sur les champs de géolocalisations
- d’accéder via l’identifiant pivot
rnb_idà des référentiels métiers plus complets dans leurs domaines respectifs (BDTOPO batiment…) en vue d’obtenir des informations utiles supplémentaires au secteur de la santé (performances énergétiques des bâtiments par GHT, données d’accessibilité, présence d’ascenceurs…) et de démontrer l’intérêt des données liées.
La faisabilité d’un tel alignement est “visualisable” avec QGIS par exemple.
Ce FINESS+ servira de base aux implémentations Toobib mentionnées plus haut requêter les pharmacies sur un territoire donné par exemple et de base de discussions avec les différents responsables des référentiels source en vue de les améliorer.
Matériels et méthodes
Le challenge retenu consiste donc à aligner le FINESS et le RNB. Cette section synthétise les informations essentielles à connaître sur ces référentiels.
FINESS
Description du FINESS
Voir par exemple:
- framagit.org/terminos/irene/-/blob/main/finess/doc/README.md
- framagit.org/terminos/irene/-/blob/main/finess/doc/README-jsom.md
Données géolocalisées du FINESS
Des données récentes géolocalisées du FINESS sont disponibles dans ce .zip au format GeoJSON en WGS84.
Les données FINESS au format OWL et OMOP sont disponibles sur framagit.org/terminos/irene/-/blob/main/finess.
Traitement du FINESS en Python
Le code source du projet BQSS de la HAS traite le fichier FINESS en Python, avec notamment :
def convert_coordinates_to_wgs84(finess_df: pd.DataFrame) -> pd.DataFrame:
...
Sa documentation est disponible ici.
Traitement du FINESS en R
Le projet FINESS etalab traite le FINESS avec R.
Référentiel National des Bâtiments (RNB)
Description du RNB
Le site du RNB pointe vers la documentation technique facilitant l’utilisation du RNB et de ses API, sachant que la création du RNB a nécessité un travail de définition du bâtiment.
Données du RNB
Le RNB est disponible en téléchargement CSV sur le site data.gouv.fr.
Les champs sont les suivants :
| Champs | Type et Taille | Description |
|---|---|---|
| rnb_id varchar(12) | L’identifiant RNB du bâtiment | |
| point | geometry eWKT | La géométrie d’un point sur le bâtiment |
| shape | geometry eWKT | La géométrie du bâtiment |
| status | varchar() | Le statut du bâtiment |
| ext_ids | json | Identifiants du bâtiment dans la BDNB et la BDTOPO |
| addresses array Tableau des adresses du bâtiment | ||
| code_dept | varchar(3) | (optionnel, fonction export national versus export par département) Code du département du point |
Exemple de géométrie ponctuelle au format eWKT :
SRID=4326;POINT(5.057550620559569 45.84776805257559)
API RNB
- API “Identification de bâtiment” par “address” et par “point”
- API de recherche de bâtiments par “Bounding box”
- API de récupération des détails d’un bâtiment
Référentiel BD TOPO
Description de la BD TOPO
Disponible en PDF et notamment BDTOPO Batiment page 63.
Données de la BD TOPO
La BD TOPO est alignée sur le RNB (champ “identifiants_rnb”).
Ses champs pour le volet “bâtiments” sont :
| Champ | Type |
|---|---|
| cleabs | xsd:string |
| nature | xsd:string |
| usage_1 | xsd:string |
| usage_2 | xsd:string |
| construction_legere | xsd:boolean |
| etat_de_l_objet | xsd:string |
| date_creation | xsd:dateTIme |
| date_modification | xsd:dateTIme |
| date_d_apparition | xsd:date |
| date_de_confirmation | xsd:date |
| sources | xsd:string |
| identifiants_sources | xsd:string |
| methode_d_acquisition_planimetrique | xsd:string |
| methode_d_acquisition_altimetrique | xsd:string |
| precision_planimetrique | xsd:double |
| precision_altimetrique | xsd:double |
| nombre_de_logements | xsd:int |
| nombre_d_etages | xsd:int |
| materiaux_des_murs | xsd:string |
| materiaux_de_la_toiture | xsd:string |
| hauteur | xsd:double |
| altitude_minimale_sol | xsd:double |
| altitude_minimale_toit | xsd:double |
| altitude_maximale_toit | xsd:double |
| altitude_maximale_sol | xsd:double |
| origine_du_batiment | xsd:string |
| appariement_fichiers_fonciers | xsd:string |
| identifiants_rnb | xsd:string |
Ces données sont disponibles par département et par thèmes sur le site de l’IGN.
API BD TOPO
Voir la doc irene/finess pour l’intégration de BDTOPO dans QGis par exemple.
Autres données et API d’intérêt
- geo.api.gouv.fr
- gateway.api.esante.gouv.fr/fhir
- api.gouv.fr/les-api/base-adresse-nationale
- adresse.data.gouv.fr/api-doc/adresse
- smt.esante.gouv.fr/fhir/CodeSystem/
Outils d’intérêts
GIS (Geographic information system) : jOSM et QGIS.
Résultats
L’algorithme d’alignement produit un CSV FINESS auquel est ajouté les 6 colonnes suivantes:
finesset_latitude: latitude de l’ES en WGS84 issue de la conversion depuis les données FINESS, ex. 46.22274483202441finesset_longitude: longitude de l’ES en WGS84 issue de la conversion depuis les données FINESS, ex. 5.2085961326419605rnb_id: id RNB proposé par l’algorithme d’alignement, ex. “QBAAG16VCJWA”rnb_score: score “interne” assigné à l’alignement RNB proposé, ex. 1.0rnb_relation: relation d’alignement proposée par l’algorithme, prise dans le jeu de valeur hwww.hl7.org/fhir/valueset-concept-map-relationship.html union build.fhir.org/valueset-iana-link-relations.html, ex. hl7.org/fhir/concept-map-relationshiprnb_algo: GUID identifiant l’algorithme utilisé pour proposer l’alignement RNB, ex. “a174b42a-f2ff-49cc-9765-37b28cf3737a”
Le nom du fichier de sortie est du type :
etalab-cs1100507-stock-20240717-0337___RNB_datagouvfr_publication_2024-03-07_16-28-06.csv (concatenation via des ___ des x fichiers sources utilisés).
Le fichier de sortie est un CSV encodé en UTF-8 qui contient donc les colonnes suivantes:
| Colonne | Remarque |
|---|---|
| structureet | — |
| nofinesset | — |
| nofinessej | — |
| rs | — |
| rslongue | — |
| complrs | — |
| compldistrib | — |
| numvoie | — |
| typvoie | — |
| voie | — |
| compvoie | — |
| lieuditbp | — |
| commune | — |
| departement | — |
| libdepartement | — |
| ligneacheminement | — |
| telephone | — |
| telecopie | — |
| categetab | — |
| libcategetab | — |
| categagretab | — |
| libcategagretab | — |
| siret | — |
| codeape | — |
| codemft | — |
| libmft | — |
| codesph | — |
| libsph | — |
| dateouv | — |
| dateautor | — |
| datemaj | — |
| numuai | — |
| finesset_latitude | latitude de l’ES en WGS84 issue de la conversion depuis les données FINESS, ex. 46.22274483202441 |
| finesset_longitude | longitude de l’ES en WGS84 issue de la conversion depuis les données FINESS, ex. 5.2085961326419605 |
| rnb_id | id RNB proposé par l’algorithme d’alignement, ex. “QBAAG16VCJWA” |
| rnb_score | score “interne” assigné à l’alignement RNB proposé, ex. 1.0 |
| rnb_relation | relation d’alignement proposée par l’algorithme, prise dans le jeu de valeur (hl7.org/fhir/valueset-concept-map-relationship.html unionbuild.fhir.org/valueset-iana-link-relations.html), ex. {“system”: “hl7.org/fhir/concept-map-relationship”, “code”:“equivalent”, “display”:“Equivalent”} |
| rnb_algo | GUID identifiant l’algorithme utilisé pour proposer l’alignement RNB, ex. “a174b42a-f2ff-49cc-9765-37b28cf3737a” |
Le code source produit est mis à disposition sur framagit LOv2 à l’adresse suivante framagit.org/interhop/challenges/datathon-2024.
Les ressources produites alimenteront les pages “réutilisation de données” de data.gouv.fr pour les référentiels utilisés (FINESS, RNB, BDTOPO…) mentionnant les pages du datathon.
Une mesure de la performance de l’alignement (F-Measure) est proposée.
Discussion
Le choix de l’implémentation de l’algorithme est libre :
- langage de programmation utilisé
- “pipe” d’alignement : via l’adresse, puis via les coordonnées WGS83, ou l’inverse, en best effort sur le Bounding box, par approche lexicale ou structurelle, par proximité sémantique, par apprentissage / embedding…
- l’ajout de colonnes supplémentaires est possible (pour signifier la détection d’un problème dans les données FINESS d’origine, pour debugger, pour proposer une correction, pour préciser la source / le JSONPath de l’alignement proposé…)
L’exercice peut être limité lors du datathon à un sous-ensemble de données (par exemple à un département ou une région) si l’exercice devait s’avérer être trop long en temps d’exécution. Dans ce cas, l’algorithme conçu doit démontrer sa scalabilité potentielle (mesure du temps d’exécution, règles de 3/anticipation des temps sur les datasets complets).
L’exercice peut être complété par le même type d’exercice d’alignement sur le RPPS afin d’avoir une base de données géolocalisée de “lieux de soins”.
Passé le datathon, le travail peut être complété (alignement avec les ressources européennes de INSPIRE, définition de référentiels syntaxiques “communs” - FHIR address, schema.org/Place ou schema.org/Organization…) et faire l’objet d’une publication.
Datathon InterHop 2024 - Sujets
Ce billet de blog vise à renseigner une liste prélimitaire des sujets qui seront traités lors du hackathon sur données (Datathon) organisé par l’association InterHop en septembre 2024.
Cette liste de proposition est indicative et évoluera en fonction de l’envie des participants.
Pour plus d’informations voici en lien le billet de blog présentant les modalités pratiques de réalisation de ce Datathon.
Voici le replay de la réunion d’information sur les modalités pratiques de réalisation du datathon.
La principale source de données utilisée est MIMIC au format OMOP. Les participant.es doivent anticiper la création de leur compte sur physionet avec notamment la signature de l’accord sur l’utilisation des données (DUA).
Nous vous donnons rendez-vous le jeudi 8 août à 13h00 dans le cadre d’une réunion du groupe interCHU pour la constitution des équipes.
FINESS+
Thème principaux
- Data engineering
- Data science
Synopsis
La santé prend le virage des parcours coordonnés de soin. Cette ambition nécessite d’avoir des données concernant l’offre de soin qui soient à jour.
Il s’agit en particulier de tenir à jour les données géographiques élémentaires (géolocalisation des 100 000 établissements de soins recensés au FINESS) dans des systèmes ouverts comme OpenStreetMap (OSM) de sorte que ces informations restent exactes et interopérables (tags et iconographies documentés et à jour).
Ce maintien à jour pourra être fait (au moins en partie) au sein de l’association Toobib.org.
En savoir plus
Voici le lien vers le billet de blog expliquant en détail ce sujet.
Indicateurs d’activité de maternité
Thèmes principaux
- Data visualization
- Data engineering
- Data science
Synopsis
L’ensemble des maternités de France fournissent annuellement des indicateurs d’activité : nombre de sièges, de césariennes, de transferts, de péridurales…
Ce sujet concerne la visualisation des données puisqu’il s’agit de présenter ces indicateurs sous forme de graphiques et de façon dynamique.
Pour ce projet nous aimerions utiliser l’outil de data science opensource LinkR.
En savoir plus
Voici le lien vers le billet de blog expliquant en détails ce sujet.
Qualité des données
Thème principal
- Data cleaning / Pre-processing
Synopsis
Ce sujet concerne la production d’indicateurs de qualité pouvant être partagés et réutilisės.
Pour ce projet nous aimerions utiliser l’outil de data science opensource LinkR. Il sera basé sur le modèle de donné open source OMOP.
En savoir plus
Voici le lien vers le billet de blog expliquant en détails ce sujet.
Prédiction de mortalité
Thème principaux
- Statistiques
- Data science
Synopsis
Ce sujet concerne la réalisation d’un sujet de data science facile à mettre en oeuvre d’un point de vue statistique. La difficulté consistera à rendre l’algorithme facilement réutilisable sur un autre jeu de données au format OMOP.
Nous entraînerons des modèles de prédiction (machine learning) afin de prédire la mortalité en réanimation, à partir des données d’admission.
A l’heure actuelle, la majorité des études comparent la mortalité de groupes de patient à l’aide de scores de gravité tels que l’IGS-2 (très ancien) et le SOFA (plus récent).
L’apport du machine learning permettrait d’avoir des modèles de prédiction de mortalité avec de meilleures performances.
Nous comparerons ces modèles aux scores SOFA et IGS-2.
Pour ce projet nous aimerions utiliser l’outil de data science open source LinkR, qui permet le partage et la réutilisation de projets de data science très facilement.
Ainsi, durant le Datathon, vous développerez vos modèles sur le set de données MIMIC-OMOP (base de données nord-américaine). Vous pourrez ensuite appliquer ce projet (avec l’ensemble des scripts le composant) à vos données locales, sans avoir à repartir de zéro.
Ce sujet s’appuiera sur la base de données MIMIC-OMOP : il s’agit d’une base de données nord-américaine (hôpital de Boston) sur une quizaine d’années, totalisant environ 50000 patients.
En savoir plus
Voici le lien vers le billet de blog expliquant en détails ce sujet.
Aide au codage CIM-10
Thème principaux
- Data science
- Large language models
Synopsis
L’apport des Large Language Models (tels que ChatGPT pour le plus connu) permet d’exploiter les données de façon plus optimale, notamment avec les Chatbots.
La base de données CIM-10 est complexe, et il est parfois difficile de trouver les diagnostics que nous recherchons. Les requêteurs “classiques” que nous trouvons sur internet utilisent des outils de recherche classique (à base de regex) non optimaux.
Les LLM, grâce au RAG (retrieval augmentated generation) permettent d’utiliser les LLM en les “nourrissant” de fichiers, tels qu’un fichier CSV contenant l’ensemble des diagnostics.
Ainsi, il est possible d’utiliser un LLM déjà entraîné, de lui fournir la base de données CIM-10 et de l’interroger directement pour nous donner les codes demandés.
L’approche par RAG a l’avantage de diminuer le risque d’hallucinations.
L’avantage de ce projet est une application immédiate ! Si vous êtes médecins, vous pourrez utiliser cel algorithme depuis votre PC perso pour aider au codage de vos patients.
Nous utiliserons la base de données CIM-10 au format OMOP.
En savoir plus
Voici le lien vers le billet de blog expliquant en détails ce sujet.