Comment améliorer la conception de l'interface utilisateur médicale

Temps de lecture : 7 minutes

En 1990, la FDA a publié un rapport, Device Recalls: A Study of Quality Problems, qui révélait que 44 % des rappels de dispositifs médicaux étaient dus à des problèmes de conception et qu'un tiers d'entre eux étaient dus à une interface utilisateur (UI) défectueuse. Le tumulte qui en a résulté a conduit les États-Unis à adopter rapidement la loi sur la sécurité des dispositifs médicaux. Ce règlement est en place depuis plus de trente ans maintenant, donc les problèmes médicaux d'assurance-chômage appartiennent sûrement au passé, n'est-ce pas ?

Malheureusement non. Une étude récente a révélé qu'environ 140 dispositifs médicaux par an sont toujours rappelés en raison de problèmes d'interface utilisateur.

Peut-on faire quelque chose à ce sujet ? Ce blog passe en revue les principaux facteurs à l'origine des problèmes d'interface utilisateur médicale et examine les recommandations spécifiques que les équipes de logiciels d'interface graphique embarquée peuvent utiliser pour créer des dispositifs médicaux de nouvelle génération sûrs et utilisables.

Trois nouvelles forces agissent sur les processus de développement de logiciels médicaux, et elles peuvent interagir de manière à conduire à une mauvaise conception de l'interface utilisateur médicale.

Malheureusement, des calendriers de produits plus rapides, des cycles de développement plus longs et des interfaces graphiques plus sophistiquées conduisent à des cycles de développement de produits sans suffisamment de temps pour des tests d'utilisabilité et des itérations d'interface utilisateur adéquats.

Comment pouvons-nous améliorer les conceptions d'interfaces utilisateur médicales ? Une grande question est de savoir si oui ou non les équipes de développement tirent parti des connaissances existantes sur l'ingénierie appropriée du facteur humain. Il y a beaucoup de matériel à ce sujet; voici quelques-unes de nos ressources préférées.

• Une introduction aux facteurs humains dans les dispositifs médicaux
• Comprendre les exigences réglementaires de la FDA pour les tests d'utilisabilité des facteurs humains
• Équilibre entre esthétique et convivialité dans la conception d'interfaces utilisateur médicales : 9 tendances clés
• Webinaire sur la conception et la sécurité de l'interface utilisateur dans les dispositifs médicaux
• CEI 62366-1:2015 : Application de l'ingénierie de l'utilisabilité aux dispositifs médicaux
• ANSI/AAMI HE75:2009 : Ingénierie des facteurs humains - Conception de dispositifs médicaux
• Normes ADA 2010 pour une conception accessible

La plupart de ces ressources donnent des indications, mais peu sont complètement prescriptives. On s'attend à ce que la majorité des principes de conception soient exécutés dans le cadre d'études d'utilisabilité correctement menées. Avec des calendriers de plus en plus courts et une complexité croissante, intégrer ne serait-ce qu'une seule itération de tests d'utilisabilité dans un calendrier de développement, et encore moins plusieurs, peut sembler impossible. La plus grande question est peut-être, si les tests d'utilisabilité sont si cruciaux, comment les équipes médicales trouvent-elles suffisamment de temps pour les mener ?

Un processus de développement standard doit généralement attendre que la conception matérielle, les cartes de prototypage, les systèmes d'exploitation et tous les autres composants de support soient raisonnablement stables avant que l'interface graphique puisse être testée. Étant donné des délais plus courts, il est facile de voir que cela entraînera des problèmes. Tout moment pour le développement, le raffinement et les tests d'utilisabilité de l'interface graphique est pressé dans les dernières semaines avant la sortie. Cela rend beaucoup plus probable que la pression pour expédier l'emportera sur la nécessité d'éliminer toutes les lacunes restantes de l'interface graphique.

Quelle est la manière idéale de concevoir une IHM médicale à la fois stable et intuitive ? La réalisation clé est que le développement de l'interface graphique doit commencer dès que les exigences du produit sont solidifiées, même si le matériel n'est pas encore prêt . Cela garantit que suffisamment de temps peut être consacré à la résolution des problèmes de convivialité. Si les développeurs peuvent découvrir rapidement les problèmes d'interface graphique, ils ont le temps de corriger les problèmes où les utilisateurs interprètent mal les données, saisissent par erreur des chiffres erronés, acceptent de mauvaises configurations par défaut, ignorent les avertissements critiques ou sont amenés à des hypothèses incorrectes.

Voici les trois directives architecturales essentielles de l'interface graphique que vous devez connaître pour dissocier l'interface graphique du reste du développement :

• Plate-forme indépendante - isolez autant que possible les composants GUI de l'application du matériel. Choisissez également des outils de développement, tels que Storyboard, pour exécuter l'interface utilisateur sur un ordinateur portable, une tablette ou une carte de référence, permettant aux tests d'utilisabilité dans un environnement simulé de se dérouler parallèlement au développement matériel.
• Contrôleur de vue de modèle (MVC) - un modèle de développement des meilleures pratiques, les architectures MVC séparent les données de l'interface graphique et centralisent tout code qui relie les deux ; si une partie du système change, l'effet sur le code est minime.
• Piloté par les événements - un autre paradigme d'ingénierie logicielle, la programmation pilotée par les événements maintient les actions de l'interface graphique isolées de la logique fonctionnelle du système. Cette séparation permet également au framework d'injecter des événements, permettant à l'interface graphique de simuler le matériel et d'être testée par programmation .

La plupart des développeurs expérimentés conviendraient que leurs projets doivent respecter ces principes, mais les plans les mieux conçus tournent souvent mal. À la fin du projet, tous les objectifs nobles qui maintiendraient une interface graphique isolée du reste d'un système ont été abandonnés. Afin d'accélérer le processus de développement, les expériences de prototypage deviennent du code de production et la logique métier s'insinue dans l'interface graphique. Ces écarts faciles à ignorer se produisent en petites quantités au fil du temps, mais le résultat final est que l'interface graphique devient dépendante des fonctionnalités sous-jacentes. Cette dépendance rend l'interface graphique fragile - elle ne peut pas être facilement modifiée sans casser le produit.

La fragilité de l'interface utilisateur se produit à moins que les développeurs n'exercent une discipline extrême lors des modifications logicielles. Au moins, cela est vrai lorsque l'interface graphique partage le même langage et les mêmes outils que le reste des fonctionnalités de l'appareil. En d'autres termes, si la logique principale du produit et le framework de l'interface graphique sont tous deux écrits en C++, les programmeurs qui introduisent des modifications doivent décider exactement quoi et où réside chaque modification, car leur code pourrait éventuellement aller à l'un ou l'autre endroit. Un petit correctif qui appartient logiquement à la fonctionnalité sous-jacente de l'appareil peut être plus facile à mettre en œuvre dans l'interface graphique. Mais une fois que ce correctif est dans l'interface graphique, il est très difficile de trouver le temps de revenir en arrière et de le réparer correctement.

Cependant, si les directives d'architecture de l'interface graphique sont suivies (c'est-à-dire, être indépendant de la plate-forme, utiliser le modèle MVC et utiliser une interface graphique pilotée par les événements), il n'y a aucun avantage inhérent à ce que l'interface graphique et le développement grand public partagent le même langage et le même cadre. Une réalisation clé est que si l'interface graphique et la logique utilisent des cadres et des langages différents, cela exercera une pression subtile sur les développeurs pour qu'ils renforcent continuellement les directives architecturales qui maintiennent l'interface graphique flexible et adaptable.