Alors que l'Internet des Objets envahit nos vies, comment intégrer cette tendance dans les équipements médicaux où la sécurité du patient n’est pas une option ? Yannick Chamming's, fondateur de Witekio, spécialiste du design et du développement de systèmes logiciels complexes pour les objets intelligents, nous livre des pistes concrètes.

Yannick Chamming's (©Jean-Jacques Raynal)

Par Yannick Chamming's, Directeur Général de Witekio

La cabinet de conseil et de recherche Gartner annonce qu’en 2020 la technologie IoT sera intégrée dans 95 % des nouveaux produits contenant de l’électronique ! Qui dit IoT, dit partage de volumes importants de données, lesquelles sont ensuite analysées et traitées dans le cloud, corrélées avec les données d’autres équipements par des algorithmes de traitement de données massives (big data). C’est par le croisement de volumes importants de données hétérogènes que la création de valeur s’opère, en créant de nouveaux usages ou en apportant des services ou des solutions qui ne seraient pas disponibles autrement. Par exemple, dans le monde du médical, nous pouvons imaginer la corrélation entre des données de diagnostic fournies par des DM et des données statistiques sur les modes de vie, le climat, la pollution, etc…

Cette démarche implique de facto la connectivité des équipements, le partage d’informations, la sécurisation du flux d’informations ou l’interopérabilité entre plusieurs équipements via des fonctions de communication "machine-to-machine". Autant de fonctionnalités qui ne sont pas "naturellement" intégrées dans les DM, et qui nécessitent d’être adaptées aux enjeux spécifiques du marché médical.

Optimiser la faisabilité du projet en isolant les fonctionnalités critiques

Le développement d’un nouveau système intégrant du logiciel peut paraître assez rebutant. Il est important d’avoir en tête les enjeux d’une telle démarche, afin d’évaluer la faisabilité et la viabilité d'un projet IoT médical.

Le point principal à prendre en compte est la nécessité d’une conformité du système au standard médical indispensable à toute commercialisation.

Tout DM doit être développé dans une démarche qualité conforme à la norme ISO 13485. Nous nous intéresserons ici à la norme IEC 62304 qui se concentre sur la partie développement logiciel.

Le premier point clé consistera à analyser la criticité du système, par le biais d’une analyse de risque. Le produit sera classifié de la criticité faible (classe A, sans impact patient fort) à la criticité la plus forte (classe C, impact patient fort, voire risque de décès). L’effort de développement logiciel est très différent selon la classe. La classe A est focalisée sur la documentation et le suivi des développements après production pour y intégrer les risques découverts a posteriori. La classe C demande des efforts plus importants comme une architecture logicielle orientée test très poussée, une documentation précise avec un suivi des exigences au travers de l’architecture, du code et de la validation.

Une fois la criticité identifiée, il s’agira alors d’évaluer les solutions d’architecture hardware et software pour faciliter le développement logiciel et limiter les investissements.

Plusieurs approches sont possibles...

On peut développer tout le logiciel nécessaire au produit dans la classe demandée. C'est envisageable pour un produit très simple ou dans une classe de criticité faible. Lorsque les fonctionnalités du produit sont plus sophistiquées, et notamment que la connectivité est introduite, cela peut devenir rapidement épineux. Si la criticité est élevée, cela implique à coup sûr un développement long et complexe (architecture, documentation, tests) qui peut rapidement devenir difficile à soutenir.

Une autre approche consiste à isoler de façon matérielle les fonctionnalités présentant un risque majeur. Elle consiste généralement à prévoir un microcontrôleur dédié aux fonctionnalités critiques (ou aux vérifications critiques) avec un code logiciel très réduit facilitant la certification. Les autres fonctionnalités peuvent ainsi être implémentées sur un autre microcontrôleur avec une classe de criticité plus faible. Cela permet de minimiser les efforts de développement.

Enfin, il est possible d'isoler de façon logicielle les fonctionnalités présentant un risque majeur. L’approche décrite précédemment peut avoir un impact non négligeable sur l’électronique, et donc sur le coût des composants électroniques, l’encombrement, la consommation électrique… La viabilité même d’un projet peut s’en trouver questionnée. On peut alors envisager une approche similaire, mais au niveau logiciel cette fois.

Il s'agit de mettre en œuvre et certifier un logiciel appelé hyperviseur. Celui-ci permet d’isoler différents environnements logiciels. Le principe est de garantir que les différents logiciels exécutés en parallèle ne pourront pas interagir en dehors d’un cadre convenu : pas de contamination possible, volontaire ou non, en dehors d’un cadre prévu dans les spécifications ; pas de débordement mémoire.

Les fonctions critiques peuvent ainsi s’exécuter dans un environnement sécurisé, quand les couches logicielles qui gèrent la connectivité et le transfert de données vers le cloud sont exécutées dans un autre environnement logiciel.

Une fois cette phase d’analyse et de décision accomplie, on a une vision plus claire de la faisabilité et des enjeux du projet. Il s’agit ensuite d’ajouter à cette vision "safety" la vision "sécurité des données".

Agir à plusieurs niveaux pour sécuriser les données

La mise en œuvre de scenarii "Internet des Objets" dans le cadre de matériel médical implique la cohabitation de deux univers qui ont des enjeux et des prérequis parfois contradictoires. D’un côté, une solution IoT implique la fourniture d’un maximum d’informations, et donc l’ouverture et la connectivité des équipements entre eux et au cloud. D’un autre côté, ces informations concernent la santé de personnes et entrainent des contraintes de sécurité, de confidentialité, peu compatibles avec une logique de forte connectivité, d’ouverture et de partage de données.

Plusieurs briques technologiques peuvent être mises en œuvre pour garantir la robustesse de l’architecture d'un DM IoT, tout en intégrant les solutions de connectivité permettant un partage d’informations sécurisé. La pertinence de ces solutions doit être validée par une expertise en architecture système, avec une très bonne compréhension des enjeux technologiques.

Il faut d'abord sécuriser le système logiciel. Il s'agit de mettre en place un système de démarrage à plusieurs niveaux que l’on appelle "Chain of trust" (chaine de confiance).

Hardware, bootloader, système, application métier... : grâce à un système de cryptographie asymétrique avec clé publique/clé privée, chaque maillon signe et valide l’authenticité du maillon suivant avant de le faire démarrer.

Dans un système connecté, il s’agit de sécuriser les échanges. On fait appel au mécanisme de "provisioning" : des clés avec certificat sont écrites dans le produit au moment même de sa fabrication. Ces clés permettent l’identification et la reconnaissance du matériel par le cloud. Cette sécurisation impliquant la phase même de fabrication du produit, il faudra mettre en place une "root of trust" avec des certificats donnant autorité aux usines et sous-traitants par exemple, et permettant de les révoquer en cas de nécessité.

Il faut ensuite prévoir un mécanisme de mise à jour à distance sécurisé. Cette étape est indispensable, d'abord parce qu’aucun système logiciel n’est infaillible dans le temps. Il faut se laisser la possibilité de le mettre à jour lorsque des failles sont identifiées et réclament des corrections. De plus, toutes les interfaces clients évoluent, et il sera certainement nécessaire de faire des modifications, d’ajouter de nouvelles fonctionnalités, etc.

Il convient également de choisir entre un Cloud spécialisé semi-public ou privé. Afin de répondre aux enjeux de confidentialité et de sécurité propres au domaine des DM, certains fournisseurs d’infrastructures proposent des solutions cloud spécialisées, garantissant notamment la haute sécurisation du stockage des données, voire de leur transfert. On notera par exemple des solutions comme VH Healthcare, FollowMed, ou même, chez les "géants" du cloud, Google Healthcare ou Microsoft HealthVault.

Enfin, il convient de voir les choses autrement avec l’Edge Computing. A la différence du "Cloud computing", il s'agit de ne pas transmettre l’intégralité des données brutes dans le cloud, mais d'effectuer un pré-traitement des données directement au niveau de l'équipement. Dans le contexte qui nous intéresse, cette approche peut aussi permettre d’adresser la problématique de sécurité des données sensibles, en réalisant leur traitement localement et en ne transmettant ainsi à l’extérieur du dispositif que des résultats "pré-digérés", potentiellement moins sensibles.

Maîtriser l'architecture systèmes

En conclusion, il est important de garder à l’esprit que chaque scenario est différent. Les choix technologiques et la manière de les articuler entre eux seront totalement différents selon la typologie du DM, sa vocation, le type de données manipulé, le niveau de sécurité nécessaire, l’environnement d’utilisation et les scenarii d’usages envisagés.

La clé du succès pour ce type de développement est d’intégrer, dès les premières étapes du projet, une expertise en architecture système, pour apporter une vision globale des enjeux logiciels, tant en termes d’usages que de contraintes systèmes ou technologiques.

witekio.com