Développer un logiciel pour le secteur de la santé — exigences, coûts et pièges

Faire développer un logiciel sur mesure pour le secteur de la santé est fondamentalement différent d'une boutique en ligne ou d'un tableau de bord interne. Cela ne tient pas uniquement à la technique — cela tient au système d'exigences, de responsabilités et de surveillance qui entoure le secteur de la santé. Celui qui le sous-estime paie le prix plus tard : en retards, en reprises, ou pire encore, en un produit qui ne peut pas être mis en service.

Cet article est destiné aux établissements de soins, aux entrepreneurs du secteur de la santé et aux décideurs qui envisagent de faire développer un produit numérique — d'un portail patient à un système de reporting ou un DPI propre. Il donne une image honnête de ce que ce parcours implique, ce qu'il coûte et quelles sont les erreurs les plus fréquentes.

La réglementation que vous ne pouvez pas ignorer

NEN 7510 — sécurité de l'information dans le secteur de la santé

NEN 7510 est la norme néerlandaise pour la sécurité de l'information dans le secteur de la santé. Comparable à ISO 27001, mais spécifiquement axée sur la protection des données médicales. Pour de nombreuses organisations de soins, la certification NEN 7510 est obligatoire ou contractuellement exigée par les assureurs santé et les organisations faîtières.

Ce que cela signifie en pratique pour un projet logiciel : le prestataire doit être en mesure de démontrer que le système répond aux exigences de sécurité de la norme. Cela nécessite un contrôle d'accès basé sur les rôles, la journalisation de qui a consulté quelles données et quand, le chiffrement des données en transit et au repos, et un processus documenté de réponse aux incidents. Ce ne sont pas des options à ajouter après coup — elles doivent être intégrées dans la conception dès le premier jour.

RGPD et données médicales

Les données médicales relèvent des données personnelles sensibles dans le RGPD. Leur traitement est en principe interdit, sauf s'il existe une base légale explicite. Dans le secteur de la santé, cette base est souvent la relation de traitement (article 9, paragraphe 2h du RGPD), mais cela ne vous dispense pas d'autres obligations.

Une agence logicielle qui développe des logiciels de santé agit juridiquement en tant que sous-traitant. Cela signifie qu'un accord de sous-traitance est obligatoire, que la minimisation des données doit être mise en œuvre dans la conception, et que les violations de données doivent pouvoir être signalées dans les 72 heures à l'Autorité de Protection des Données. Les organisations de soins qui délèguent cela à une agence sans accord de sous-traitance sont elles-mêmes responsables.

Cartes UZI et authentification

Pour les systèmes qui donnent accès au Point de Commutation National (LSP) ou qui travaillent avec le registre BIG, l'authentification via des cartes UZI (Identification Unique du Prestataire de Soins) est requise. Ce sont des cartes à puce qui enregistrent l'identité d'un prestataire de soins. Toutes les agences n'ont pas d'expérience avec les intégrations UZI — et ce n'est pas une tâche technique triviale.

Les systèmes qui n'ont pas besoin de connexion directe au LSP peuvent aussi fonctionner avec DigiD (pour les patients) ou d'autres moyens d'authentification certifiés, selon le niveau de risque.

SMART on FHIR et interopérabilité

L'une des exigences les plus sous-estimées des logiciels de santé est l'interopérabilité : l'exigence que les systèmes puissent communiquer entre eux. Aux Pays-Bas, FHIR (Fast Healthcare Interoperability Resources) est la norme pour l'échange de données médicales. SMART on FHIR est un cadre d'autorisation qui s'y ajoute et permet une connexion sécurisée avec des systèmes externes.

Si votre nouveau système doit, même partiellement, communiquer avec un DPI (Dossier Patient Informatisé), un système de médecin généraliste ou le LSP, le support FHIR n'est pas un luxe — c'est une condition préalable. Beaucoup de logiciels standard ne le supportent pas ou de manière incomplète. Le logiciel sur mesure peut l'intégrer, mais cela augmente la complexité et les coûts.

Lors d'un entretien avec une agence, demandez toujours explicitement : avez-vous déjà développé des intégrations FHIR ? Avez-vous des références dans le secteur de la santé ? Une agence qui est vague à ce sujet ne l'a probablement pas fait.

Applications courantes

Les logiciels de santé ne sont pas tous aussi complexes. Quelques cas d'usage courants, classés par complexité :

Portail patient — Un environnement sécurisé où les patients peuvent consulter leurs rendez-vous, remplir des questionnaires ou envoyer des messages. Relativement simple en périmètre, mais nécessite la conformité RGPD, l'intégration DigiD et une bonne UX pour un groupe d'utilisateurs diversifié.

Système de planning pour les professionnels de soins — Plannings, rendez-vous, disponibilités. Le défi réside dans la logique de planning complexe (contrats à temps partiel, spécialisations, localisations) et l'intégration avec les systèmes RH ou DPI existants.

Dossier de soins ou DPI — Le type le plus complexe. Enregistrement structuré des plans de soins, données de traitement, médicaments. Nécessite la standardisation via FHIR, un audit robuste, et souvent l'intégration avec des systèmes externes comme les logiciels de pharmacie ou le LSP.

Reporting aux autorités sanitaires — De nombreuses organisations de soins doivent périodiquement faire des rapports à l'Autorité néerlandaise de Santé (NZa) ou aux assureurs santé. Les logiciels qui automatisent cela doivent correspondre exactement aux codifications DBC requises et aux formats de déclaration.

Pourquoi les logiciels de santé sont plus chers

La différence de prix entre une application web classique et un logiciel de santé a trois causes.

Charges de conformité — Documentation, audit de sécurité, test de pénétration et démonstration de conformité à NEN 7510 nécessitent du temps supplémentaire. C'est un travail qui n'est pas visible dans l'interface utilisateur finale, mais qui est nécessaire pour pouvoir mettre le système en service.

Complexité des intégrations — Les connexions avec les systèmes DPI, l'infrastructure UZI, le LSP ou les endpoints FHIR sont techniquement exigeantes. Ce ne sont pas des connexions API standard — elles nécessitent des certificats, des protocoles spécifiques et des tests approfondis.

Exigences de test — Dans le secteur de la santé, les erreurs peuvent avoir des conséquences directes sur la sécurité des patients. Cela nécessite une stratégie de test plus étendue, comprenant des tests d'acceptation fonctionnels avec les utilisateurs finaux (professionnels de soins), et parfois une certification en tant que dispositif médical sous le MDR (Medical Device Regulation).

Indications budgétaires réalistes

Pour les logiciels de santé, d'autres normes budgétaires s'appliquent qu'au développement sur mesure standard :

• Portail patient (de base) : 40 000 – 70 000 €. Y compris DigiD, messagerie sécurisée, aperçu des rendez-vous et conformité RGPD. Sans intégration DPI.
• Portail patient avec connexion DPI : 80 000 – 140 000 €. Selon le DPI et les interfaces disponibles.
• Système de planning : 60 000 – 120 000 €. Très dépendant de la complexité du planning et du nombre d'intégrations.
• DPI ou EPD complet : 150 000 – 400 000 €+. C'est du sur mesure dans la catégorie la plus lourde. Attendez-vous à un parcours de 9 à 18 mois avec une équipe multidisciplinaire.

En plus des coûts de construction viennent les coûts récurrents : hébergement (de préférence aux Pays-Bas ou dans l'UE, sur une infrastructure certifiée), maintenance, revues de sécurité annuelles et éventuelle recertification.

Les pièges qui affectent le plus les organisations de soins

Choisir une agence sans références dans le secteur de la santé. Techniquement, de nombreuses agences peuvent développer une application. Mais une agence qui n'a jamais travaillé dans le secteur de la santé ne connaît pas les exigences de conformité de l'intérieur. Conséquence : vous payez un processus d'apprentissage que le prestataire facture à votre compte.

Reporter la conformité à après la construction. La sécurité et la conformité RGPD ne sont pas une couche de peinture que vous appliquez après coup. Celui qui les intègre après la première version reconstruit effectivement le système. Planifiez la conformité comme exigence de première classe, pas comme une étape ultérieure.

Ne pas tenir compte des modifications de réglementation. Le secteur de la santé se numérise rapidement, et la réglementation évolue en parallèle. Les systèmes qui sont conformes aujourd'hui devront peut-être être adaptés dans deux ans. Assurez-vous qu'il y a un contrat de maintenance et que l'agence est disponible sur le long terme.

Oublier l'utilisateur. Les professionnels de soins sont occupés. Un système qui ne fonctionne pas intuitivement n'est pas utilisé — quel qu'en soit le coût. Investissez dans la recherche utilisateur et testez tôt avec de vrais professionnels de soins et des patients.

Trouver la bonne agence

Lors des entretiens avec des agences, demandez des références concrètes dans le secteur de la santé. Pas seulement « nous avons déjà fait quelque chose dans la santé », mais : quel système, pour quelle organisation, avec quelles intégrations, et quelles étaient les exigences de conformité ? Demandez aussi l'accord de sous-traitance — une agence qui ne peut pas en parler directement a peu d'expérience avec le RGPD dans le secteur de la santé.

Vérifiez si l'agence est familière avec NEN 7510, FHIR et l'infrastructure de santé néerlandaise. Ce ne sont pas des points bonus — ce sont des qualifications de base pour ce type de travail.

Développer des logiciels de santé est complexe, mais gérable si vous savez ce que vous achetez. Les organisations qui réussissent leur numérisation ne sont pas celles qui ont le plus grand budget — ce sont celles qui trouvent le bon partenaire et posent les bonnes questions.