Création de logiciel sur mesure en santé : les étapes
La création d'un logiciel sur mesure en santé pour gérer une patientèle se joue avant le développement : il faut délimiter le parcours à outiller, répartir les responsabilités sur les données et choisir un hébergement adapté. Le code vient ensuite. Un projet réussi commence par une première version réduite, utilisée par une seule personne en conditions réelles, et non par une liste de toutes les fonctions imaginables.
Création d'un logiciel sur mesure en santé : qui répond de quoi
Trois acteurs se croisent et les confusions coûtent cher. Selon le référentiel de la CNIL pour le secteur de la santé et la FAQ de l'Ordre des médecins, le professionnel libéral reste responsable de ses données, même s'il confie leur hébergement. Le prestataire ne le libère pas de cette responsabilité : le contrat doit traiter la protection des données, la sécurité, et le rendu ou la destruction en fin de contrat.
| Sujet | Qui décide | Ce qu'il faut obtenir par écrit |
|---|---|---|
| Données collectées et leur durée de conservation | Le cabinet, avec son conseil si besoin | Une liste des champs et une règle par type de donnée |
| Hébergement | Le cabinet, sur proposition du prestataire | Le certificat de l'hébergeur et son périmètre d'activités |
| Administration de la production | À trancher dès le départ | Qui a accès, comment c'est tracé, quel statut pour cette personne |
| Code et documentation | Le contrat | Propriété ou licence, remise du code et procédure d'installation |
La ligne sur l'administration est celle que je vois le moins citée dans les devis. Le référentiel HDS retient six activités, dont l'administration et l'exploitation du système d'information contenant les données et leur sauvegarde, comme le détaille le cabinet CMS. Un serveur certifié ne règle donc pas automatiquement la situation de la personne qui l'administre pour vous. Faites analyser ce point avant de confier les accès, car je ne peux pas le trancher à la place d'un juriste.
Les étapes d'un projet réaliste
La première étape est d'observer. Suivez une vraie journée et notez d'où vient chaque rendez-vous, chaque message et chaque document, et qui les traite. Cette observation remet souvent en cause l'idée de départ : on croit vouloir un dossier patient alors qu'on perd surtout du temps sur les reports de rendez-vous.
La deuxième est de réduire le périmètre. Choisissez le parcours qui coûte le plus aujourd'hui et isolez-le : c'est votre première version. Ajoutez à ce moment-là les décisions sur les données. Chaque champ doit avoir une raison d'être. Le mieux pour protéger une donnée de santé est de ne pas la collecter quand elle ne sert pas.
La troisième est de construire avec des données fictives, puis de faire tester l'outil par la personne qui l'utilisera. Les écrans se valident à l'usage, pas sur une maquette. Prévoyez les droits d'accès, la double authentification et un journal des actions dès le début : ces éléments sont difficiles à rajouter proprement ensuite.
La quatrième est la mise en service. Si vous reprenez des données existantes, faites une répétition, contrôlez un échantillon et gardez l'ancien outil accessible pendant la période de transition. La cinquième dure aussi longtemps que le logiciel : correctifs de sécurité, sauvegardes testées, mises à jour du framework et évolutions réglementaires. Prévoyez-la au budget dès le départ, sinon un outil sans suivi devient vite un risque.
Les fonctions à ne pas bricoler
Certaines fonctions semblent simples et ne le sont pas. Le courriel de rappel en est un exemple : son objet et son contenu peuvent révéler une information de santé sur l'écran verrouillé d'un téléphone. Il vaut mieux y mettre le strict minimum. La CNIL rappelle par ailleurs que les fichiers contenant des données personnelles ne doivent pas circuler en clair par des messageries grand public : un compte rendu en pièce jointe n'est donc pas une bonne idée.
La suppression est un autre piège. Elle paraît être un droit à offrir partout, alors que l'Ordre des médecins indique que le droit à l'effacement ne s'applique pas au dossier médical. Distinguez donc le compte de réservation, qui peut être supprimé, du dossier soumis à conservation. Enfin, tout ce qui touche à la feuille de soins électronique relève d'un parcours spécifique : la facturation SESAM-Vitale passe par un agrément ou une homologation du logiciel. Je ne recommande pas de se lancer dans cela pour un seul cabinet.
Un exemple concret, et sa limite
J'ai réalisé pour Emmanuelle Audard, psychologue clinicienne, une application de gestion de patientèle centrée sur l'organisation du cabinet : les créneaux, la réservation par les patients et les courriels, avec un journal d'audit et l'export des données. Il s'agit d'un exercice individuel, sans télétransmission. Si votre projet réunit plusieurs praticiens, avec des dossiers partagés, c'est un autre niveau de complexité : demandez à tout prestataire, moi compris, une preuve correspondant à ce cas.
Quand ne pas lancer le projet
Je gagne ma vie avec ce type de développement, donc gardez cela en tête en me lisant. Un logiciel sur mesure n'est pas une bonne idée quand votre besoin est couvert par un produit établi à un coût raisonnable, quand personne ne pourra tester régulièrement, ou quand le budget s'arrête le jour de la mise en ligne. Si vous voulez commercialiser votre outil auprès d'autres professionnels, le projet change de nature : vous devenez éditeur, avec un travail de conformité, de support et de responsabilité qui dépasse un développement pour votre seul cabinet.
La prochaine étape
Rédigez une page : qui utilise l'outil, le parcours à améliorer, ce que vous utilisez aujourd'hui et les données en jeu. Avec cela, on peut déjà dire si un développement a du sens. Ma page sur le logiciel métier détaille ma façon de travailler, et vous pouvez me transmettre ce texte. Vous parlerez directement à la personne qui écrit le code, avec une réponse sous 24 heures ouvrées.