LAB Stats : cartographie de laboratoires

Contexte

Les réseaux de laboratoires de biologie médicale couvrent des territoires étendus. Pour décider où renforcer un réseau de prélèvement ou ouvrir un site, il faut voir d'un coup d'œil où sont les patients, qui les prélève, qui les adresse et où se trouvent les concurrents.

Ces données existaient, mais dispersées dans les exports des systèmes d'information de laboratoire (SIL), sous forme de fichiers et d'adresses postales.

Le problème à résoudre

• Transformer des fichiers en données exploitables — importer des exports hétérogènes et les rattacher entre eux.
• Passer de l'adresse au point sur la carte — géocoder chaque laboratoire, préleveur et patient.
• Croiser les couches — superposer réseau, concurrents, patients et limites administratives pour lire la couverture territoriale.
• Lire une zone en un clic — obtenir les indicateurs d'un code postal sans exporter vers un tableur.

Contraintes

• Formats d'import variables — chaque SIL produit ses propres fichiers CSV ou TSV.
• Adresses imparfaites — le géocodage échoue sur une partie des enregistrements ; il faut savoir lesquels et pourquoi.
• Lisibilité de la carte — des marqueurs nombreux doivent rester lisibles et la carte fluide.
• Données de santé — des informations sur des patients, à traiter avec rigueur.

Choix techniques et pourquoi

• Des loaders d'import par format de SIL — un format nouveau se traite par un loader dédié, sans toucher au reste du pipeline.
• Géocodage en lot avec suivi de statut — l'API adresse.data.gouv.fr en premier, Google Maps en complément, et un statut par enregistrement pour repérer les adresses à corriger plutôt que de les perdre silencieusement.
• MongoDB pour les données géolocalisées — un stockage par documents, adapté à des enregistrements dont la structure varie selon le SIL d'origine ; Redis en cache applicatif.
• AngularJS et Leaflet côté client — une application monopage centrée sur la carte, avec MarkerCluster pour regrouper les marqueurs et un plugin Heatmap pour lire la densité de patients.
• Limites administratives en GeoJSON — régions, départements et communes enrichis des données de population INSEE, pour rapporter les volumes à la population.

Ce qui a été livré

• Gestion des jeux de données — import multi-format avec suivi de progression et validation.
• Couche laboratoires — réseau et concurrents distingués par couleur, hiérarchie groupe, société, laboratoire.
• Couche patients — marqueurs, clusters ou carte de chaleur, patients directs et indirects, filtrage par laboratoire.
• Couches préleveurs et correspondants — infirmiers préleveurs et prescripteurs sur la carte.
• Limites administratives — communes et départements colorés selon la population.
• Statistiques par zone — au clic : nombre de patients, part de prélèvements directs et indirects, laboratoires et concurrents par code postal.

Résultats

La plateforme a été livrée en 2017. Elle donne aux décideurs du réseau une lecture cartographique de leur couverture : zones peu desservies, pression concurrentielle par secteur et maillage des préleveurs, construite directement à partir des exports des systèmes de laboratoire.

Stack

• Back-end — PHP, Symfony (API REST)
• Front-end — AngularJS, Leaflet (MarkerCluster, Heatmap), Bootstrap
• Données — MongoDB, Redis, GeoJSON et données INSEE
• Services externes — API adresse.data.gouv.fr, Google Maps Geocoding

Pour aller plus loin

Ce projet relève de mon offre de développement web sur mesure. Sur la conception de l'API qui alimente ce type d'application, voir l'article concevoir une API REST maintenable.