Détermination de besoins logiciels pour dispositifs médicaux : cas d'étude

Situation et problématique

Un nouveau dispositif médical doit être mis au point par une entreprise du secteur biomédical. Disons que ce dispositif requiert

• un logiciel de dispositif médical pour l'utilisation du dispositif par les clients de l'entreprise et
• un logiciel pour assurer la production / fabrication du dispositif par l'entreprise.

Si les fonctionnalités du logiciel nécessaires à la fabrication du dispositif sont proches de celles requises pour l'utilisation du dispositif, deux approches semblent possibles :

• faire un seul logiciel pour assurer l'utilisation et la fabrication du dispositif ou
• faire deux logiciels distincts, un pour chaque usage identifié.

De prime abord, il peut paraître plus intéressant pour le fabricant de prévoir un unique logiciel pour ces deux utilisations. Mais est-ce vraiment le cas ?

Comparons ces deux approches.

Comparaison des deux approches

Comparaison du point de vue normatif

Si on considère les fonctionnalités de contrôle du dispositif, on traite d'un logiciel de dispositif médical qui doit être conçu et développé suivant les exigences de la norme EN 62304, entre autres.

Et si on considère les fonctionnalités destinées à la fabrication du dispositif, le logiciel qui les implémente devra respecter les exigences de la norme ISO/TR 80002-2 (voir Faire des logiciels non médicaux dans le secteur biomédical).

Ainsi, en faisant deux logiciels distincts, on diminue le nombre d'exigences normatives à respecter par le logiciel destiné à l'utilisation du dispositif.

Comparaison de la quantité de travail totale

Avec une approche à deux logiciels distincts, le travail de réalisation de chacun des logiciels se focalise sur les fonctionnalités qu'ils doivent assurer.

Par contre, avec un unique logiciel, il faudra peut-être faire un mécanisme de contrôle pour passer d'un mode d'utilisation à l'autre.

Ainsi, la quantité de travail total nécessaire risque d'être plus importante avec une approche à un unique logiciel pour assurer les deux types d'utilisation.

Comparaison en termes d'aptitude à l'utilisation

Dans le cas d'une approche avec deux logiciels distincts aucun problème particulier ne se pose : on conçoit deux interfaces graphiques distinctes et adaptées aux utilisations prévues.

Par contre, dans le cas d'une approche avec un unique logiciel, on a le choix entre prioriser l'une des utilisations pour la conception de l'interface ou faire deux interfaces graphiques distinctes avec un basculement de l'une à l'autre.

Si on priorise l'utilisation du logiciel par les clients pour concevoir son interface graphique, ne risque-t-on pas de favoriser des erreurs dans le cadre de la fabrication du dispositif ?

Inversement, si on priorise l'utilisation du logiciel par le département de fabrication, ne risque t'on pas de dégrader l'interface pour une utilisation par les clients de l'entreprise ?

Enfin, si on choisit de faire deux interfaces graphiques distinctes, n'est-on pas en train de construire, de facto, deux logiciels distincts.

Comparaison en termes de robustesse du résultat

L'article Comment réduire le coût d'un logiciel de dispositif médical ? montrait que plus un logiciel assure de fonctionnalités et plus sa probabilité de dysfonctionnement est élevée.

Sur cette base, le besoin de maintenance corrective est beaucoup plus probable avec l'approche à un unique logiciel qu'avec l'approche à deux logiciels distincts.

Comparaison en termes d'analyse de risques du dispositif médical

Dans le cadre de l'analyse de risques du dispositif médical, toutes les fonctionnalités incluses dans le logiciel d'utilisation du dispositif doivent être prises en compte.

De nouveau, dans le cas d'une approche avec deux logiciels distincts, aucun problème particulier ne se pose.

Par contre, dans le cadre d'une approche avec un unique logiciel, les fonctionnalités liées à la fabrication du dispositif doivent être incluses dans l'analyse de risques du dispositif.

Quelles seraient les conséquences possibles si un client tombait sur le mode d'utilisation réservé à la production ? Est-ce que ces fonctionnalités changent la classe de sécurité du logiciel ?

Pour répondre à ces questions il faut avoir en tête la règle de classification de sécurité du logiciel énoncée dans la norme CEI EN 62304 :

Si le phénomène dangereux peut résulter d'une défaillance du système logiciel à se comporter conformément aux spécifications, la probabilité d'une telle défaillance doit être supposée de 100%.

---

Source : Norme CEI EN 62304

Comparaison en termes de maintenance

L'approche avec un unique logiciel amène aussi des questions en rapport avec la maintenance du logiciel.

Comment va-t-on gérer les retours d'utilisation concomitants des clients d'une part et du service de fabrication des dispositifs d'autre part ?

Est-ce que les évolutions du logiciel requises par le service de fabrication vont devoir attendre un besoin d'évolution soulevé par les clients de l'entreprise ?

Est-ce qu'on sera amené, pour le service de fabrication, à faire des versions du logiciel différentes de celles distribuées aux clients ? Ne sera t-on pas, dès lors, dans le cas de deux logiciels différents ?

Le choix le plus intéressant pour le fabricant

On le voit bien : l'approche à un unique logiciel, en apparence intéressante, pose un certain nombre de problèmes :

• la quantité globale de travail de conception et développement risque d'être augmentée en comparaison avec la réalisation de deux logiciels distincts,

• la probabilité de dysfonctionnement du logiciel obtenu sera plus élevée que dans le cas de deux logiciels distincts,

• l'ergonomie du logiciel risque d'être diminuée pour l'une des deux utilisations prévues,

• l'analyse de risques du dispositif va être impactée par des fonctionnalités du logiciel dont les clients n'ont pas besoin,

• la maintenance évolutive des fonctionnalités liées à la fabrication risque d'être impactée par les besoins de maintenance liés aux fonctionnalités d'utilisation du dispositif.

Ainsi, faire un logiciel pour les clients et un autre pour le service de production s'avère bien plus intéressant pour le fabricant de dispositifs médicaux.

Mais une question subsiste suite à ces observations : est-ce que pour faire deux logiciels distincts il faudra développer deux fois des fonctionnalités similaires ?

Bien évidemment la réponse est non.

Une approche de conception et développement par composants réutilisables permetra à l'entreprise de n'investir qu'une fois dans le développement des fonctionnalités communes aux deux logiciels.

Ces composants "métier" feront partie des actifs de l'entreprise. Ils augmentent donc sa valeur et son prix en cas de revente éventuelle.

Pour en savoir plus

La norme ISO/TR 80002-2 aide à concevoir et développer du logiciel non médical dans le secteur biomédical.

Pour un logiciel (de) dispositif médical, l'analyse de risques permet de prévenir les dysfonctionnements du logiciel.