Archives de catégorie : Santé

Guide : Mon logiciel a-t-il une finalité médicale ?

Dev, Santé, Securité,

Répondre à cette question est crucial pour savoir si votre logiciel est soumis à la réglementation des dispositifs médicaux (DM). Voici une méthode claire et structurée pour évaluer votre logiciel.

Étape 1 : Comprendre la notion de « finalité médicale »

Un logiciel a une finalité médicale s’il est destiné à :

  1. Diagnostiquer une maladie ou une affection.
  2. Prévenir l’apparition ou l’aggravation d’une condition médicale.
  3. Surveiller une condition clinique ou un état de santé.
  4. Traiter ou atténuer une maladie, une blessure ou un handicap.
  5. Compensation d’une déficience ou d’un handicap.
  6. Aider à la prise de décision médicale, directement ou indirectement.

Exemple :

  • Logiciel médical : Un outil d’analyse d’images IRM pour détecter des tumeurs.
  • Pas médical : Une application organisant des rendez-vous médicaux, car elle ne traite pas directement la santé.

Étape 2 : Poser 5 questions clés

  1. Quel est l’objectif principal de mon logiciel ?
    • S’il prétend résoudre un problème lié à la santé, il est probablement médical.
  2. Exemple :
    • Oui : Une application qui analyse la glycémie pour ajuster un traitement.
    • Non : Un outil de suivi d’activités physiques (sans finalité médicale directe).
  3. Influence-t-il des décisions diagnostiques ou thérapeutiques ?
    • S’il fournit des informations influençant un diagnostic ou un traitement, il pourrait être un DM.
  4. Exemple :
    • Oui : Un logiciel calculant le dosage d’un médicament basé sur des paramètres cliniques.
    • Non : Un simple gestionnaire de stocks de médicaments.
  5. Traite-t-il des données patients dans un contexte médical ?
    • Les logiciels interprétant des données de santé sont souvent qualifiés de dispositifs médicaux.
  6. Exemple :
    • Oui : Une application analysant des ECG pour détecter des arythmies.
    • Non : Un outil générant des statistiques anonymes sur des données de santé publique.
  7. A-t-il un effet direct ou indirect sur la santé des utilisateurs ?
    • Si le logiciel aide ou impacte le bien-être médical d’un individu, il peut être considéré comme médical.
  8. Exemple :
    • Oui : Une application prédictive pour évaluer les risques de diabète.
    • Non : Un outil de rappel de prise de médicaments, sans analyse des données.
  9. Le fabricant déclare-t-il une finalité médicale ?
    • Les intentions marketing et les descriptions techniques jouent un rôle déterminant.
  10. Exemple :
    • Oui : Un logiciel décrit comme « permettant le diagnostic précoce des cancers ».
    • Non : Un logiciel décrit comme « facilitant la gestion administrative en clinique ».

Étape 3 : Utiliser l’arbre décisionnel

Étape 4 : Étudier des exemples concrets

Exemple 1 : Application de suivi de sommeil

  • Fonctionnalités : Mesure des mouvements et conseils pour améliorer le sommeil.
  • Analyse : Pas un DM, car il ne diagnostique ni ne traite un trouble du sommeil.
  • Conclusion : Logiciel de bien-être.

Exemple 2 : Analyseur de radiographies

  • Fonctionnalités : Détection automatique d’anomalies sur des images radiologiques.
  • Analyse : C’est un DM, car il aide au diagnostic médical.
  • Conclusion : Logiciel DM (classe IIa ou IIb).

Exemple 3 : Gestion des plannings d’hôpitaux

  • Fonctionnalités : Organisation des rendez-vous et suivi des équipes médicales.
  • Analyse : Pas un DM, car aucun impact sur les décisions médicales.
  • Conclusion : Logiciel administratif.

Exemple 4 : Outil d’analyse prédictive

  • Fonctionnalités : Évaluation des risques de maladies cardiovasculaires.
  • Analyse : DM probable, car il influence des décisions médicales basées sur des données cliniques.
  • Conclusion : Logiciel DM (classe IIa).

Étape 5 : Vérifier la réglementation applicable

Si votre logiciel répond à la définition de finalité médicale :

  1. Consultez le règlement MDR 2017/745 ou IVDR 2017/746.
  2. Appliquez les règles de classification pour déterminer sa classe.
  3. Préparez les étapes de conformité (dossier technique, marquage CE, etc.).

Si votre logiciel ne répond pas à la finalité médicale, vous pouvez le qualifier comme un logiciel de bien-être ou un outil à usage général.

Conclusion

Pour savoir si votre logiciel a une finalité médicale, évaluez :

  1. Son objectif principal.
  2. Son impact sur les décisions médicales.
  3. Les données traitées.
  4. La finalité déclarée par le fabricant.

Une fois qualifié, vous saurez s’il doit respecter la réglementation des dispositifs médicaux. N’hésitez pas à consulter le guide MDCG 2019-11 pour des détails supplémentaires.

Passer de la méthodologie craft à la norme ISO 62304 : une démarche dans la continuité !

Dev, Santé, Securité, , ,

Dans le monde du développement de logiciels, la méthodologie craft et la norme ISO 62304 partagent une mission commune : garantir un code de qualité, sécurisé, et durable. Mais pour un développeur craft, se confronter à l’ISO 62304 peut sembler intimidant. Pourtant, la transition est bien plus naturelle qu’il n’y paraît. Explorons ensemble comment faire évoluer les pratiques craft pour répondre aux exigences de cette norme rigoureuse.

Norme ISO 62304

1. Qualité de code et responsabilité : une continuité naturelle

La méthodologie craft valorise un code propre, structuré et maintenable. Les développeurs craft sont déjà conscients de la responsabilité qu’ils portent sur le produit qu’ils créent. La norme ISO 62304 partage cette exigence de qualité, mais impose un cadre formalisé pour la sécurité et la conformité.

Évolution requise : En adoptant ISO 62304, la qualité de code reste primordiale, mais elle s’accompagne de standards stricts de sécurité et de documentation. Pour un développeur craft, cela signifie simplement d’approfondir les pratiques déjà en place, en renforçant leur rigueur pour garantir la sécurité des utilisateurs.

2. Documentation et traçabilité : aller au-delà des notes et des README

Les développeurs craft documentent souvent leur code via des notes claires et des README bien fournis. Avec l’ISO 62304, cette documentation devient exhaustive et doit couvrir chaque étape du cycle de vie du logiciel.

Évolution requise : La documentation passe de « complémentaire » à « essentielle ». Chaque décision, chaque modification, et chaque test doivent être documentés pour garantir une traçabilité complète. Cela peut sembler fastidieux, mais cette exigence permet d’assurer la sécurité et la conformité réglementaire sur le long terme.

3. Gestion des risques : formaliser l’instinct de tester

Dans la méthodologie craft, les tests sont souvent ciblés là où le développeur estime que le risque est le plus élevé. L’ISO 62304 formalise cette intuition en demandant une évaluation des risques à chaque étape, ainsi que des contrôles et tests renforcés sur les fonctionnalités les plus critiques.

Évolution requise : Les tests doivent maintenant répondre à une analyse des risques plus systématique. Il ne s’agit plus seulement de tester là où on le « sent » nécessaire, mais de formaliser et documenter ces décisions. Pour un développeur craft, cela revient simplement à structurer ce qui était jusque-là implicite.

4. Culture de la maintenance : renforcer la vision à long terme

Le code craft est conçu pour durer, avec une attention particulière portée à la maintenabilité. La norme ISO 62304 pousse cette vision encore plus loin, en imposant une gestion de la maintenance rigoureuse pour assurer la sécurité dans le temps.

Évolution requise : Les procédures de maintenance et de mise à jour doivent être clairement documentées et systématiques. Cela renforce l’approche craft d’un code durable, en rendant chaque étape formalisée pour s’assurer que le logiciel peut être mis à jour et corrigé de façon sécurisée.

Conclusion : La norme ISO 62304 comme une méthodologie craft institutionnalisée

Finalement, l’ISO 62304 n’est que la forme la plus formalisée de la méthodologie craft, adaptée aux exigences du secteur médical. La norme transforme les bonnes pratiques craft en exigences réglementaires, en les structurant pour assurer une sécurité maximale.

Pour un développeur craft, cette transition est moins une rupture qu’une évolution logique. En acceptant cette rigueur supplémentaire, il est possible de développer des logiciels qui allient excellence et sécurité pour le bien-être des patients et des utilisateurs.

Passer d’un artisan du code à un expert sous norme, c’est aussi devenir le garant de la sécurité et de la fiabilité dans un domaine où chaque fonctionnalité peut faire la différence.

ISO 62304 : Une norme essentielle pour le développement de logiciels médicaux

Dev, Santé, Validation

La norme ISO 62304, publiée par l’Organisation internationale de normalisation (ISO), définit les exigences du cycle de vie des logiciels destinés aux dispositifs médicaux. Son objectif est de garantir que les logiciels utilisés en milieu médical sont conçus, développés, testés et maintenus de manière à assurer sécurité et fiabilité pour les patients et les utilisateurs.

Cet article passe en revue les aspects principaux de la norme ISO 62304 et son rôle dans la conformité réglementaire et la gestion des risques.

1. Contexte de la norme ISO 62304

L’ISO 62304 est une norme internationale qui fournit un cadre rigoureux pour le cycle de vie des logiciels médicaux. Dans l’industrie de la santé, les logiciels ne sont pas de simples applications : ils peuvent impacter directement la sécurité des patients et des utilisateurs. La norme vise donc à structurer les étapes de développement, en introduisant des contrôles et des validations pour chaque étape clé, afin d’assurer que chaque composant du logiciel répond aux plus hauts standards de sécurité.

Objectif : garantir que les logiciels médicaux sont sûrs, efficaces et conformes aux exigences réglementaires dans les différents marchés.

2. Structuration du cycle de vie du logiciel

Le cycle de vie du logiciel est central dans la norme ISO 62304, qui se compose des phases suivantes :

  • Planification du développement : cette étape inclut la création d’un plan structuré qui définira les objectifs du logiciel, les responsabilités des équipes et les procédures à suivre.
  • Analyse des exigences : il est crucial de définir les exigences fonctionnelles et techniques dès le départ pour assurer que toutes les attentes sont claires.
  • Conception : à partir des exigences, la conception du logiciel est élaborée. Elle décompose les fonctionnalités en modules qui seront ensuite développés.
  • Implémentation : il s’agit de l’étape de codage, où chaque composant est développé en respectant les spécifications de conception.
  • Tests et validation : une phase de tests rigoureuse permet de vérifier que chaque fonctionnalité fonctionne comme prévu et respecte les exigences de sécurité.
  • Libération et maintenance : une fois le logiciel testé et validé, il est mis en production. La norme exige également une documentation des procédures de maintenance pour assurer la sécurité du logiciel dans le temps.

En résumé, rien d’insurmontable. Il faut juste avoir une roadmap solide et anticiper les tests de son logiciel. Le  minimum que l’on devrait avoir dans un développement.  La norme 62304 est l’antithèse de la norme 1664 un peu trop en vogue dans notre milieu …

l

3. Classification des logiciels selon le niveau de risque

L’ISO 62304 introduit une classification du logiciel en fonction de son impact potentiel sur la sécurité des patients. Il existe trois classes principales :

  • Classe A : les défaillances du logiciel n’entraînent aucun risque pour la sécurité.
  • Classe B : une défaillance du logiciel pourrait causer des blessures légères ou modérées.
  • Classe C : une défaillance pourrait entraîner des blessures graves ou la mort.

Le niveau de risque détermine les exigences de documentation, de validation et de tests. Plus le risque est élevé, plus les exigences sont strictes.

4. Gestion des risques

La gestion des risques est un pilier de l’ISO 62304. Elle impose aux développeurs d’identifier, d’évaluer et de maîtriser tous les risques potentiels pour les patients et les utilisateurs. Le processus de gestion des risques comprend :

  • Identification des risques : il s’agit d’identifier tous les risques possibles associés à chaque fonction du logiciel.
  • Analyse des risques : chaque risque est évalué en fonction de sa probabilité et de sa gravité.
  • Mise en place de mesures de contrôle : des mesures sont mises en œuvre pour réduire ou éliminer les risques, notamment en ajoutant des fonctionnalités de sécurité, en améliorant les processus de conception, ou en intégrant des vérifications automatiques.
  • Documentation des risques résiduels : une fois les mesures de contrôle appliquées, les risques résiduels sont documentés et validés pour s’assurer qu’ils sont acceptables.

En résumé, savoir identifier les risques de son logiciel, c’est savoir pointer du doigts les endroits où les tests devront être les plus performants. Nous sommes tous conscient que le 100 % de couverture n’est pas un but en soit, mais avoir une couverture par les tests là où sont les risques les plus important … et d’autant plus utile que le choix courant de mettre les tests … là où ils sont le plus simple à implémenter. 

5. Importance du cahier des charges et des spécifications

Un cahier des charges précis et détaillé est indispensable pour répondre aux exigences de l’ISO 62304. Ce document permet de :

  • Définir les attentes et les fonctionnalités souhaitées.
  • Garantir que tous les besoins métiers sont bien compris par les équipes techniques.
  • Servir de référence pour la validation et la conformité lors des tests.

Le cahier des charges permet également de structurer le projet de manière à garantir que chaque fonction, du début à la fin, respecte la norme et les attentes des utilisateurs.

6. Documentation et traçabilité

L’ISO 62304 impose une documentation complète de chaque étape du cycle de vie du logiciel. Chaque décision, chaque test, chaque mise à jour doit être documentée pour créer une traçabilité complète du produit. Cette documentation permet :

  • De prouver la conformité : chaque étape du développement est tracée pour montrer que le logiciel a été conçu selon les exigences.
  • D’assurer la maintenance : la documentation facilite les mises à jour et la maintenance en fournissant un historique détaillé du logiciel.
  • De gérer la validation des tests : les résultats des tests sont documentés pour prouver que le logiciel répond aux exigences de sécurité et de performance.

7. Conclusion : Un cadre rigoureux pour des logiciels sûrs et fiables

L’ISO 62304 fournit un cadre méthodique pour le développement de logiciels médicaux sûrs et fiables. Bien qu’elle impose des processus complexes et une documentation rigoureuse, ces exigences sont essentielles pour garantir la sécurité des patients et la conformité réglementaire. Pour les développeurs et les chefs de projet, comprendre et appliquer l’ISO 62304 permet de créer des logiciels qui répondent aux normes les plus strictes et inspirent confiance dans le domaine de la santé.

Un exemple où le choix de l’IA a toute son importance .

Dev, Santé, , ,

L’utilisation de l’intelligence artificielle (IA) dans le développement de logiciels est devenue presque incontournable. Dans cet article, je vais partager une expérience sur l’utilisation de l’IA pour accéder à des bases de données médicamenteuses en français.

Les avantages de l’IA dans le Développement

L’IA peut grandement accélérer le processus de développement en automatisant des tâches répétitives comme la recherche de documentation ou l’analyse de code. Par exemple, en donnant un exemple de classe, l’IA va pouvoir vous générer un template utilisable de fichier de test, elle pourra également vous montrer comment générer rapidement un ensemble de données « vraisemblable ». S’en passer serait prendre un risque important de perte d’efficacité.

Les limitations de l’IA

Cependant, il est important de noter que chaque IA a ses limitations. Dans le cas, suivant, on voit les manques de ChatGPT du, sans doute, à une actualisation des données depuis la création de ses données d’apprentissage. Sur le cas suivant, la différence de réponse va soit vous permettre d’accélérer votre travail, soit vous menez dans une solution impossible à réaliser dans un temps raisonnable.

J’ai récemment eu besoin d’accéder à une base de données médicamenteuse en français. J’ai d’abord consulté ChatGPT, qui m’a orienté vers la Base de données publique des médicaments du gouvernement français. Cependant, cette base de données ne propose pas d’API publique, ce qui limite son utilisation dans un contexte de développement. La solution proposée par chatGpt était soit de scraper le site, soit de me tourner vers des solutions concurrentes (non officiel) ou sur des données de recherche.

En revanche, la solution proposée par Bard (Google) était plus complète, offrant non seulement des informations sur la base de données mais aussi des alternatives pour y accéder. En effet, si ce site ne propose pas directement une api pour consulter ses données, il propose un téléchargement d’une série de fichier décrivant l’ensemble des médicaments . Si ce n’est une API, cela reste une méthode efficace pour avoir accès aux données souhaitées.

En conclusion,

Se fier à une unique source de données, quelles qu’elle soit, IA ou non, est une erreur. L’IA peut être un outil puissant pour les développeurs, mais il est crucial de comprendre ses avantages et ses limitations. Il faut tester et toujours mettre en doute une solution qui ne vous parait pas la plus simple.

L’adoption de la blockchain dans les applications médicales

Dev, Santé

La sécurisation des données dans les applications médicales est le point essentiel. Il vous faut toujours savoir qui, à quoi et quand une donnée est accédé. Cette donnée est sensible et soumise à une réglementation stricte. La blockchain est lune technologie qui permet de stocker et de vérifier de manière sécurisée les transactions et les données. Son adoption dans les applications médicales offre plusieurs avantages pour le secteur de la santé.

Pourquoi son adoption (ou pas) ?

La blockchain permet d’améliorer la sécurité des données médicales. Les informations médicales sont sensibles et doivent être protégées contre les accès non autorisés. La blockchain utilise des algorithmes cryptographiques avancés pour garantir l’intégrité et la confidentialité des données médicales, ce qui réduit le risque de falsification ou de violation de la vie privée. Cette technologie facilite la traçabilité et l’authenticité des données médicales. Dans le domaine de la santé, il est essentiel de pouvoir suivre l’origine et l’historique des données médicales, telles que les résultats des tests, les dossiers médicaux et les prescriptions. Grâce à la blockchain, chaque transaction est enregistrée de manière transparente et immuable, ce qui permet de vérifier l’authenticité des données et de retracer leur parcours.

La blockchain est également une technologie qui favorise l’interopérabilité des systèmes de santé. Les applications médicales peuvent utiliser la blockchain comme un protocole standard pour échanger des données médicales entre différentes plateformes et institutions. Cela facilite la collaboration et le partage d’informations entre les différents acteurs du secteur de la santé, tels que les hôpitaux, les médecins et les laboratoires.

Enfin, la blockchain offre des opportunités pour améliorer la gestion des identités dans les applications médicales. Grâce à la blockchain, il est possible de créer des identités numériques uniques et vérifiables pour les patients, les médecins et d’autres acteurs du domaine médical. Cela simplifie les processus d’identification, de vérification et d’autorisation, tout en préservant la confidentialité des données personnelles.

Les défis ?

L’adoption de la blockchain dans les applications médicales présente également des défis. Parmi ceux-ci, on retrouve la mise à l’échelle de la blockchain pour gérer un grand volume de transactions, la compatibilité avec les réglementations en matière de protection des données, et les coûts associés à la mise en place et à la maintenance d’une infrastructure blockchain.

Pour quelles types d’applications ?

Gestion des dossiers médicaux électroniques : La blockchain peut être utilisée pour créer un système sécurisé de gestion des dossiers médicaux électroniques. Les dossiers médicaux pourraient être stockés sur la blockchain, ce qui permettrait aux patients et aux professionnels de la santé d’accéder aux informations médicales de manière sécurisée et transparente, tout en préservant la confidentialité.

Suivi de la chaîne d’approvisionnement pharmaceutique : La blockchain peut être utilisée pour suivre le cheminement des médicaments depuis leur fabrication jusqu’à leur utilisation par les patients. Cela permet de garantir l’authenticité des médicaments, de lutter contre la contrefaçon et de surveiller les conditions de stockage pour assurer la qualité des produits pharmaceutiques.

Partage sécurisé des données de recherche médicale : La blockchain peut faciliter le partage sécurisé des données de recherche médicale entre différentes institutions et chercheurs. Les données pourraient être stockées de manière décentralisée sur la blockchain, garantissant ainsi la transparence, l’intégrité et la traçabilité des informations, tout en préservant la confidentialité des patients.

Gestion des consentements et autorisations : La blockchain peut être utilisée pour gérer les consentements et les autorisations des patients concernant l’accès à leurs données médicales. Les patients pourraient utiliser des identités numériques vérifiables sur la blockchain pour contrôler et donner leur consentement à différentes entités pour accéder à leurs informations médicales.

Systèmes d’assurance santé basés sur la blockchain : La blockchain peut être utilisée pour créer des systèmes d’assurance santé décentralisés et transparents. Les contrats d’assurance et les paiements pourraient être automatisés en utilisant des contrats intelligents sur la blockchain, réduisant ainsi les coûts administratifs et les risques de fraude.

Une technologie en vogue ou réelle ?

C’est aujourd’hui une technologie qui a dépassé le cadre de l’innovation. De nombreuses preuves de concept ont été réalisées … mais peut-on réellement parler d’une technologie accessible tel une brique classique.

Voici quelques pokes reconnu :

MedRec (2017) est un projet de recherche développé par le Massachusetts Institute of Technology (MIT) qui utilise la blockchain pour la gestion sécurisée des dossiers médicaux électroniques. Il permet aux patients de contrôler l’accès à leurs données médicales et de partager des informations spécifiques avec des professionnels de la santé. Ce projet datant de 2017 (https://www.media.mit.edu/publications/medrec-blockchain-for-medical-data-access-permission-management-and-trend-analysis/) expose comment il est possible de partager une information sensible en se basant sur une blockchain connue : l’Etherum.

SimplyVital Health utilise la blockchain pour développer des solutions de suivi et de partage des données de santé pour les fournisseurs de soins de santé et les patients. Leur plateforme, appelée Health Nexus, permet de stocker les dossiers médicaux, de suivre les résultats des traitements et de faciliter les remboursements d’assurance.

Lancé en 2017 et après plusieurs levée de fond importante, le projet semble inactif depuis 2021 …

Medicalchain est une plateforme basée sur la blockchain qui vise à sécuriser et à faciliter le partage des données médicales. Elle permet aux patients d’accéder à leurs dossiers médicaux, de donner leur consentement pour le partage des informations et de consulter des médecins en ligne en toute confidentialité.

Le projet semble toujours actif mais la roadmap affichée en ligne s’arrête en 2019 … Ce n’est pas bon signe …

En résumé

La technologie semble intéressante sur le papier mais pour le moment son adoption est lente. Ce qui est sur c’est que de depuis 2017, la date du papier pour le projet Medrec, la technologie blockchain n’est pas devenue un élément incontournable de la sécurisation du développement des applications médicales. Le terme blockchain ne fait pas encore part des mots clés des offres d’emploi dans le domaine des applications médicales.

Est-ce qu’il faut continuer à s’informer sur ces technologies ? Je pense que oui. Le domaine de la donnée médicale est encore trop peu sécurisé. L’échange de données non protégées est encore trop fréquent sous couvert qu’il s’agit de données anonymisées.

A suivre donc …

Crédits :

Les images proviennent de Freepik

Image de macrovector

Image de starline

Image de pressfoto

Base transparence – échec lors de la montée en charge

Dev, Open Data, Santé,

Dans l’article précédent, nous étions partis sur une extraction des données.
En effet, notre objectif était d’avoir une résultat rapide afin d’avoir des données affichages.  Nous sommes donc sur un cas d’école entre le cas utilisé par un développeur qui travail sur une extraction afin de valider ses travaux … qui échoue une fois les données de production utilisées.

En regardant le volume des données, rien de plus normal. Nous utilisons comme base de travail 3 fichiers de plusieurs gigas que nous combinons entre eux avant de faire les opérations. Autant dire que cela explose très rapidement.

En ré-ordonnant les opérations, et filtrant les données, tout rentre dans l’ordre.

Le code est le suivant :

 

self.loader.load_avantages(light)
data_avantages = self.loader.avantages[[‘entreprise_identifiant’, ‘avant_montant_ttc’]]

#calcul de la rémunération (avantage)
data = data_avantages.groupby([« entreprise_identifiant »])[« avant_montant_ttc »].sum().sort_values(ascending=False).head(nb_entreprise)

### jointure entreprise et avantage
self.loader.load_entreprises()
data_merge = merge(data, self.loader.entreprises, how= »left », left_on=[« entreprise_identifiant »], right_on= »identifiant »)
data_merge.to_excel(writer, sheet_name= »Avantage »)


A noter :

data = data_avantages.groupby([« entreprise_identifiant »])[« avant_montant_ttc »].sum().sort_values(ascending=False).head(nb_entreprise)

4 opérations dans cette ligne.

  • Le groupby permet de regrouper l’ensemble des avantages  par entreprise.
  • Le sum : permet de les cumuler
  • Le sort_values : permet de les trier dans l’ordre croissant
  • Le head permet de ne récupérer que les nb_entreprises les plus important.

Le github du projet a été mis à jour : https://github.com/SaugetMarc/transparence

 

 

 

 

 

 

Python Pandas Excel : un premier formatage

Astuce, Dev, Open Data, Santé

L’objectif de cet article est donc de montrer une chaîne complète de traitement de l’information, permettant à partir d’un ensemble de fichier résultat de type CSV, d’aller à un tableau formaté, pouvant être directement diffusé.

Le choix des données initiales

Pour avoir une base de travail, le plus simple est de partir sur des données issues de l’Open Data. Ces données sont facilement accessibles, fournies dans un résultat exploitable .. et sont souvent des mines d’information.

Mon choix c’est fait sur la base de données Transparence. Ces données sont directement accessible sur le portail suivant : transparence-santé.

La modélisation des données est la suivante :

    • Un fichier pour la description des entreprises
    • Un fichier pour la description des avantages
    • Un fichier pour la description des conventions.

La manipulation des données en Python

Nous allons faire simple, car dans ce cas précis, l’objectif est de voir comment charger les données, renseigner les jointures entre elles et produire quelques résultats.

Les données sont actuellement centrées sur l’entreprise. Notre  exemple sera de construire un graphique  contenant  les 50 entreprises les plus dépensières (convention + avantage).

Chargement et jointure des fichiers

Pour le chargement des fichiers, le plus simple est d’utiliser les méthodes mises à disposition par le frameworks Panda.  Mais avant tout chose, il est nécessaire de se faire un jeu de données possédant une taille utilisable pour les tests.

Le plus simple est de prendre une sous-sélection des fichiers de bases. Avec un environnement bash, la commande head permet de faire cela très rapidement.

head -n 50 avantage.csv > avantage_light.csv

Une bonne habitude est d’utiliser dès que possible un fichier de configuration pour votre projet.  Les chaînes magiques ont malheureusement tendance à rester beaucoup trop longtemps dans les projets

DATA = {

'avantage' : 'data/avantage_light.csv',
'convention': 'data/convention_light.csv',
'entreprise': 'data/entreprise.csv',
'remuneration':'data/remuneration_light.csv'

}

Le chargement des fichiers se fait avec la commande suivante :

defloadcsv(self):
  self.entreprises   = read_csv(settings.DATA['entreprise'], header=0, delimiter=',', error_bad_lines=False)
  self.avantages     = read_csv(settings.DATA['avantage'], header=0, delimiter=';', error_bad_lines=False)
  self.conventions   = read_csv(settings.DATA['convention'], header=0, delimiter=';', error_bad_lines=False)
  self.remunerations = read_csv(settings.DATA['remuneration'], header=0, delimiter=';', error_bad_lines=False)

Les travaux préparatoires sont maintenant terminés

Après une rapide analyse des fichiers, tous utilisent l’identifiant de l’entreprise comme données de jointure. Le seul point à prendre en compte porte sur le fait que suivant le fichier, l’identifiant n’a pas le même nom.  Il faut donc préciser le nom de la colonne pour pouvoir faire un rapprochement.

La jointure se fait donc à l’aide de la commande suivante :

data_merge = merge(self.loader.avantages, self.loader.entreprises, how="left", left_on=["entreprise_identifiant"], right_on="identifiant")
 
Puis, afin de regrouper les données par secteurs, il faut faire une opération de regroupement sur deux informations : le secteur et le nom de l’entreprise :
(La commande finale  head(50) permet de limiter l’extraction au 50 premières lignes, utile en cas de test)
 
data = data_merge.groupby(["secteur","entreprise_identifiant"])["avant_montant_ttc"].sum().head(50)
L’enregistrement basic dans un fichier excel se fait avec la commande suivante :
data.to_excel(writer, sheet_name="Avantage")
Simple, mais peu exploitable en production. En effet, le résultat obtenu n’est pas des plus présentable.
 

Construction du fichier excel formaté.

worksheet = writer.sheets["Avantage"]
format_size = 'C2:C'+str(data.shape[0]+1)
worksheet.conditional_format(format_size, {'type': '3_color_scale'})
worksheet.set_column('A:C', 20)

Avec ces 4 petites lignes, on a :

    • Déterminer la taille de la table
    • Changer le format de la dernière colonne (en gradiant)
    • Redimensionner la taille des 3 colonnes de notre table.

 

Pour aller plus loin, allez faire tour sur  Xlswriter.   L’ensemble des sources de ce petit projet sont ici. 

 

 

 

 

Power Bi, Open Data et listing des pharmacies

Astuce, BI, Open Data, Power Bi, Santé, ,

Voici un petit article présentant comment il est possible d’obtenir un listing dans Power BI présentant une grande majorité des pharmacies.

La première étape est de récupérer un fichier contenant l’ensemble des établissements de santé.
Le choix se fait sur le fichier Fichier Finess:

Le choix est déterminé par la certification du fichier et sa fréquence de sa mise à jour.

Ce dossier du site Open Data contient en fait plusieurs documents distincts dont le détail est visible dans l’aperçu précédent.

Pour ce premier article, nous n’aurons besoin que du fichier contenant les extractions Finess des établissements ainsi que la géolocalisation de ces établissements. En supplément, il est possible de consulter le 1er fichier permettant d’obtenir un descriptif des différentes informations contenus dans le dossier.

Le traitement dans Power Bi sera minimaliste. La première étape consiste à importer les différents fichiers CSV. Après import des fichiers, il faut faire attention au typage automatique des colonnes. En effet, pour se faire, Power BI fait un échantillonnage sur les premières colonnes du fichier. Dans le cas des départements, cela pose problème car le type numérique du début de fichier n’est pas conservé sur son intégralité (2A / 2B pour la corse par exemple). Il est donc recommandé de conserver le type alphanumérique pour toutes valeurs qui n’est pas un nombre exploitable. Ceci se fait très facilement en appliquant changeant le type.

Pour le fichier structure, les étapes sont les suivantes :

  1. Source : import initial
  2. Promoted Headers : permet de sélectionner la première ligne comme entête de la table
  3. Changed Type : permet de passer du type numérique à alphanumérique
  4. Merged Queries : permet de faire une jointure entre le référentiel des types de voie et la table structure.

Un autre point à mentionner est que, dans le fichier fournit, le type de voie est donné sous la forme d’un référentiel qui n’est pas fourni. Pour le construire relativement rapidement, il suffit d’utiliser un tableur et de sélectionner l’ensemble des valeurs distincte de la colonne typvoie. Une fois la sélection obtenue, il est possible de créer son propre référentiel après avoir complété l’ensemble des libellés associés.

 

Nous obtenons donc 3 fichiers qu’il est possible le lier par la suite dans l’écran de modélisation.

Un dernier point de détail concerne le widget utilisé pour la localisation des établissements. Celui fonctionne à l’aide des adresses postales. L’inconvénient est quand le fichier fourni, l’adresse est éclaté dans plusieurs champs. Un moyen simple pour contourner ce problème est d’ajouter une colonne calculée à notre table, regroupant l’ensemble des champs devant être joint. On peut voir dans cette formule l’utilisation du référentiel sur le type de voie et l’ajout, en dur, du pays. Le fichier étant localisé par nature, il ne contient pas la notion de pays.

En conclusion, nous obtenons l’ensemble des établissements de santé, géolocalisées, dans des listes filtrables.

Maisons de santé, un projet en devenir

Santé

Travaillant depuis maintenant deux ans pour un éditeur de logiciel en phase avec le monde de la santé, c’est avec un grand intérêt que je suis le projet de l’Asip Santé quand à son label maisons de la santé.

L’objectif est de permettre aux acteur de la santé de s’assurer que le logiciel qu’ils évaluent ou qu’ils possèdent répond correctement à un ensemble conséquent mais indispensable de fonctionnalités.

A l’inverse, cette homologation permet pour un éditeur de connaître, dans les grandes lignes le périmètre d’une solution pour ce type d’acteur.

A titre perso, cette définition de périmètre me permet de voir l’étendu du travail à accomplir pour réaliser ce type de développement … et après un premier passage sur le DSFT de l’Asip santé ( lien ext ), il y a du travail en perspective.