Challenge - [ED Lab Prediction]

Nom à trouver

Ce notebook est à destination de l'équipe travaillant autours du projet.
L'objectif est de présenter sommairement le projet et les données.

Rationel

Chaque jour, environ 50 000 personnes se présentent dans un service d'accueil des urgences (SAU) en France. En moyenne, 75% des patients retournent à domicile, et 20% sont hospitalisés. La durée moyenne de présence au SAU est longue. On estime que seulement 20% attendront moins d'une heure, tandis que ~30% attendront entre 1h et 2H et ~30% attendront en 2 et 4H. Enfin, un peu plus de 10% resteront au SAU entre 4 et 6H. Dans un contexte de pénurie de soignants, le recours à la consultation au SAU est en constante augmentation depuis plusieurs années. L'optimisation du circuit des urgences est une problématique centrale. Le cout humain et financier des dysfonctionnements du circuit et de l'offre de soin est important.

Le parcours classique du circuit des urgences est le suivant :

1. Premier contact d'ordre administratif
2. Premier contact soignant avec une infirmière d'accueil et d'orientation (IAO) (~M30) avec :
   • Recueil du motif de consultation
   • Prise des constantes
   • Recueil de quelques antécédents et de l'ordonnance du patient
   • Eventuellement ECG

Le patient est classé selon un score de gravité (bleu, vert, jaune, orange, rouge, ou 1-2-3-4-5)

3. Premier contact médical avec un médecin (~H1) :
   • Interrogatoire
   • Examen clinique

A la suite de cette consultation, plusieurs cas de figures selon la situation. Le patient peut sortir avec ou sans ordonnance si le diagnostic est posé par l'examen clinique et ne nécéssite ni examen, ni hospitalisation. Le patient peut nécéssiter la réalisation d'examens (prise de sang, radiographie, scanner) ou motiver un avis d'un spécialiste. Auquel cas il doit attendre

4. Réalisation des examens complémentaire ou d'un avis (prescription, réalisation, récupération)
5. Décision finale : Conclusion une fois les examens récupérés. (~H3)

Entre chaque étape, le patient attend pendant une durée plus ou moins longue. Le médecin lui « jongle » avec plusieurs patients à la fois à des étapes différentes.

Nous proposons d'aider à raccourcir le temps entre l'arrivée du patient et sa sortie, en ne subordonnant pas la décision de réaliser un examen biologique à l'examen clinique du médecin. Nous savons que le temps entre l'arrivée au SAU et la première visite avec le médecin est le temps le plus long et le plus mal vécu par les patients.

Nous proposons à l'aide d'un algorithme d'apprentissage statistique de prédire, dès les données fournies par l'IAO, la nécéssité de réaliser un examen de biologie médicale, afin de permettre aux IDE de prélever cet examen juste après l'IAO, de sorte que le médecin dès sa première visite peut conclure avec les résultats de la biologie, qu'il aurait sans cela, demandé et attendu de récuperer avant de conclure et de prendre en charge le patient.

Méthode

Nous faisons l'hypothèse que la réalisation ou non (variable qualitative binaire) d'une biologie médicale est (en grande partie) déterminée par les variables disponibles dès l'IAO.

Les étapes clés de ce projet sont les suivantes :

• I. Identifier une base de données exploitable – Verrouiller la base
  Base MIMIC-IV ED – Verrouillée et disponible via le présent dépôt
• II. Explorer et visualiser les données
  Recherche de corrélations, visualisation des données, description et analyse des inputs et output features
• III. Pre-processer les variables d'interêts
• IV. Entrainer un algorithme de machine learning avec une metric d'interet à définir

Données

Les données sont issus du projet MIMIC-IV.
Le projet MIMIC est un projet d'open-data médical initié par l'hopital Beth Israel Deaconess à Boston.
Initialement, seul des données de réanimation été accessible.

Pour sa 4ème édition, a été mis à disposition un jeu de données couvrant un spectre bien plus large :

• Données relatives aux passages aux urgences
• Données relatives aux hospitalisations
• Données relatives aux séjour en réanimation
• Données de radiographie thoracique avec compte rendu associé

L'ensemble de ces données ont été mis à disposition dans le cadre de projets complémentaires :

• MIMIC-IV : hospitalisation et réanimation
• MIMIC-IV-ED : urgences
• MIMIC-IV-CXR : radiographie thoracique

Ces bases sont complémentaires dans le sens où chaque collecte a été faite durant une période temporelle spécifique, qui se recoupe plus où moins.
Certains éléments nécessaires à l'exploitation de MIMIC-IV-ED sont présent dans MIMIC-IV.
La lecture de la documentation de MIMIC-IV et de MIMIC-IV-ED est vivement recommandé (lien ci-dessus).

En complément, un certains nombre de ressources est disponible sur le site du projet MIMIC-IV.

Nous proposons de travailler autours de ce jeu de données avec pour objectif la tache suivante : prédire les examens biologiques qui seront réalisés lors de l'arrivé d'un patient aux urgences

Téléchargement des données

La base de données de biologie étant volumineuse (nous y reviendrons plus bas), un pré-traitement des données a été effectué.
Le pré-traitement est le suivant :

• Intégration de l'ensemble des données utiles au sein d'une base de données SQLITE
• Tri des lignes de biologies afin de ne conserver que celles répondant au critères suivants :
  • Date de réalisation >= date de début du passage aux urgences
  • Date de réalisation <= date de fin du passage aux urgences

Un token de téléchargement des données vous a normallement été mis à disposition.

    pip install -r requirements.txt
    python download_data.py [TOKEN]

Le script de transformation est disponible dans database_constitution/database_constitution.py.

Chargement et exploration des données

Les données sont téléchargés dans le dossier data.
Il est facile de requêter une base sqlite à l'aide de pandas.

L'avantage de travailler avec une base sqlite, c'est qu'il nous permet de manipuler et transformer des données qui ne peuvent pas toujours tenir en mémoire vive.
Quelques exemples de traitements :

Grâce à un système d'index, les transformations de données via sqlite se font relativement rapidement.
C'est notamment le cas pour les filtre (WHERE) et les jointure. Un exemple de jointure :

Tables disponibles

L'ensemble des tables disponible est le suivant :

L'ensemble des tables correspondent aux fichiers correspondant au sein de MIMIC-IV-ED.
Il y a quelques exceptions qui proviennent de MIMIC-IV :

• labevents
• microbiologyevents
• d_labitems

d_labitems

d_labitems contient le libellé des examens de biologie.
Chaque libellé a un identifiant unique itemid. Il est utile à l'identification des examens dans la table labevents.

Plus de détail ici : https://mimic.mit.edu/docs/iv/modules/hosp/d_labitems/

labevents

labevents contient les examents de biologie ainsi que leurs résultat. Chaque examen a deux dates associés :

• charttime qui est la date de réception de l'examen, on peux la considérer comme une approximation de la date de prélèvement
• storetime date de mise à disposition du résultat de l'examen, selon l'examen celle-ci est plus où moins espacé de la date de prélèvement

Chaque ligne correspond au résultat d'un examen (par exemple, dosage du potassium, identifié par itemid) et est identifié par un identifiant unique labevent_id. Plusieurs examens peuvent être effectué sur le même prélèvement sanguin.
Chaque prélèvement est identifié par un identifiant unique specimen_id. Enfin, subject_id identifie le patient, hadm_id l'identifiant de séjour lorsque le patient a été hospitalisé au décours de son passage aux urgences et stay_id l'identifiant du passage aux urgences.

Plus de détail ici : https://mimic.mit.edu/docs/iv/modules/hosp/labevents/

microbiologyevents

Parmis les examens de biologie, certains revêtent d'un statut particulier, il s'agit des examens de microbiologie, c'est à dire les examens recherchant la présence de bactérie dans un prélèvement biologique (sang, urine, selle, liquide céphalo-rachidien ...).

Ils sont enregistrés dans une table dédié : microbiologyevents
Le champs "spec_type_desc" contient le site de prélèvement, souvent le sang (BLOOD CULTURE) où les urines (URINES) (cf plus bas).

L'interprétation de ces examens faisant l'objet de spécificté, on retrouve de nombreuses colonnes spécifiant : la valeur quantitative de l'analyse, son interprétation, le nimbre de résistance de la bactérie identifié ... En première intention, il semble qu'il s'agit de champs que nous n'aurons pas à exploiter.

Plus de détail ici : https://mimic.mit.edu/docs/iv/modules/hosp/microbiologyevents/

edstays

La table edstays contient la liste de tout les passages aux urgences.
Sont enregistré : l'identifiant du patient, l'identifiant du séjour si le patient est hospitalisé en aval de son passage aux urgences, l'identifiant du passage aux urgences, la date et heure d'entrée et sortie.

Plus de détail ici : https://mimic.mit.edu/docs/iv/modules/ed/edstays/

patients

La table patient contient la liste des patients ainsi que les information relative à leurs age et genre.
La base MIMIC-IV étant pseudonymisé, toutes les dates ont été falsifié, la table patient nous donne une approximation de la véritable date des enregistrement dans le champs anchor_year_group.

Plus d'informations ici : https://mimic.mit.edu/docs/iv/modules/core/patients/

triage

La table triage contient les données de "tri" des patients.
Le circuit classique d'un passage aux urgences est le suivant :

• Enregistrement administratif du patient
• Patient reçu rapidement par un infirmier (en France on parle d'infirmier d'accueil et d'orientation, où IAO)
• Un niveau de sévèrité est attribué au patient par l'IAO
• Le médecin voit ensuite le patient, dès qu'il le peut, par ordre de priorité et d'attente
• Si le médecin a besoin de plus d'éléments, il prescrit des examens complémentaires au patient

Ainsi, l'ensemble des informations disponible à l'arrivé du patient sont enregistré dans cette table.

Le champs chiefcomplaint est un champs de texte libre, le reste contient des variables quantitative de paramètre vitaux recueillis par l'IAO.
Ce champs peux contenir une liste, qui est alors séparé par une virgule.
Il s'agit d'un champs qui a fait l'objet d'une désidentification, ainsi si une information personnelle était présente dans la liste, elle est remplacé par le caractère "___" (3 underscore à la suite).

medrecon

La table medrecon contient la liste des traitements habituels du patient.
Par traitement habituel, on entends les traitement que le patient prenait avant même son passage aux urgences.

Ces traitements sont tous identifiés à l'aide d'identifiant produit :

• NDC - National Drug Classification (de la NDA)
• GSN - Generic sequence number

Les traitements ont été regroupés à l'aide d'une classification nommé "Enhanced Therapeutic Class", chaque groupe est identifié par un code etccode associé au libelé du groupe etcdescription.

Une analyse plus poussée des traitements pourrait être nécessaires, elle imposerait d'exploiter le code produit NDC.
L'idéal est d'obtenir un code ATC, qui est une classification fonctionnelle très pratique pour identifier l'indication des médicaments.
Une approche pourrait être de se reposer sur l'API de la National Library of Medicine (https://lhncbc.nlm.nih.gov/RxNav/).
Une travail similaire a été effectué par d'autres personnes : https://github.com/fabkury/ndc_map

diagnosis

Bien que ne faisant pas partit de l'objet du projet, la table diagnosis a été inclut dans l'éventualité où nous aurions besoin de l'explorer.
L'ensemble des diagnostic sont identifié à l'aide de la classification internationale des maladie dans sa version 9 (ICD-9).