Termes et définitions relatifs aux logiciels des dispositifs médicaux – CEI 62304 et FDA (2e partie)

Termes et définitions relatifs aux logiciels des dispositifs médicaux – CEI 62304 et FDA (2e partie)

Cet article fait partie de notre série consacrée à la CEI 62304, qui vise à aider à comprendre la norme et à la mettre en œuvre correctement dans le cadre du développement de logiciels pour dispositifs médicaux.

Articles précédents :

• Comment démarrer la mise en œuvre de la norme CEI 62304
• Termes et définitions relatifs aux logiciels des dispositifs médicaux – Partie 1

Voici la deuxième partie de notre examen des termes définis dans la norme CEI 62304. Dans cet article, nous aborderons les concepts suivants :

• ARCHITECTURE
• CONCEPTION DÉTAILLÉE DU LOGICIEL
• SYSTÈME ET SYSTÈME LOGICIEL
• SOUP/OTS
• TRAÇABILITÉ
• CYCLE DE VIE DU PRODUIT

Si vous ne possédez pas encore votre propre exemplaire de la norme CEI 62304, vous pouvez l'acheter à un prix très raisonnable sur www.evs.ee, le Centre estonien de normalisation et d'accréditation.

(Nous vous recommandons de choisir la licence multi-utilisateurs au format PDF. Elle est beaucoup plus facile d'accès et de lecture, sans nécessiter de logiciel supplémentaire avec des plugins de protection des droits d'auteur.)

Vous pouvez également trouver la formulation officielle de la plupart des termes et définitions sur le site web de l'ISO.

Comprendre le terme vous fera avancer

Tout au long de ma carrière de consultant, j'ai souvent rencontré des situations où les équipes ne s'accordaient pas sur la terminologie utilisée dans les normes qu'elles suivaient. Cela conduit généralement à des discussions récurrentes pour savoir si les procédures opérationnelles standard (SOP) internes sont réellement conformes aux normes, ou si les termes utilisés dans les processus internes correspondent véritablement à ceux décrits dans les normes.

Il est important de garder à l’esprit que toutes les normes ISO et CEI ont évolué au fil du temps ; elles n’ont pas été créées d’un seul coup. De ce fait, vous constaterez naturellement certaines divergences entre elles. Ce qui importe plus que de rechercher la définition « parfaite » d’un terme, c’est de décider comment votre organisation l’interprétera, de documenter cette interprétation et de l’appliquer de manière cohérente.

Disposer de termes et de définitions clairement définis permet à votre organisation de les utiliser de manière cohérente dans tous les processus. Cela facilite également leur adaptation ou leur mise à jour lorsque cela est nécessaire, garantissant que tout le monde parle le même langage et contribuant à éviter toute confusion lors des audits.

Vous trouverez ci-dessous la deuxième série de termes et de définitions que nous utilisons chez QMLogic pour aider nos clients à élaborer leurs procédures internes. Celles-ci s’appuient non seulement sur notre expérience en matière de conception de processus selon la norme CEI 62304, mais aussi sur notre participation à de nombreux audits et sur notre travail concernant les constatations des clients et les projets de mesures correctives (CAPA).

Architecture et conception architecturale dans la norme CEI 62304

Le terme Architecture est simple pour de nombreux développeurs, et la norme CEI 62304 n'y consacre d'ailleurs que peu de place dans la section « Termes et définitions ». Elle le décrit simplement comme une structure organisationnelle d'un système ou d'un composant.

Malgré son apparente simplicité, ce terme pose de nombreux problèmes au sein des organisations, principalement en ce qui concerne la traçabilité ou les liens avec les diverses activités qui y sont associées.

En poursuivant la lecture de la norme CEI 62304, vous rencontrerez ce terme à de nombreux endroits, et les exigences définies en matière d’architecture vous révéleront sa véritable signification. De plus, vous constaterez que la norme fait la distinction entre l’architecture et la conception architecturale.

Et sans une bonne compréhension de cette distinction, vous pourriez avoir des difficultés à vous conformer à la norme.

Conception architecturale

La conception architecturale est une activité. C'est ce que les architectes logiciels, ou les développeurs en général, font régulièrement au cours de certaines étapes spécifiques de la conception et du développement. En revanche, le résultat de cette activité est l'architecture elle-même.

Tout au long du processus de conception et de développement, vous refléterez les exigences logicielles dans l'architecture, définirez les interfaces entre les composants logiciels et identifierez les composants SOUP/OTS (voir le chapitre suivant) afin de les intégrer dans le système logiciel global.

Toutes ces étapes font partie de la conception logicielle — le processus consistant à définir la structure, les composants et les interfaces du logiciel afin de répondre aux exigences spécifiées.

Tout ce qui résulte de ces activités est ensuite documenté sous le nom d’architecture.

Architecture logicielle

Une erreur courante — et une source fréquente de difficultés pour les équipes de développement — consiste à considérer l’architecture logicielle comme un simple diagramme graphique. Cependant, une image seule ne peut pas rendre compte de toutes les activités et de tous les résultats de la conception architecturale, telle que définie précédemment.

La norme IEC 62304, section 5.3.6, stipule qu’une vérification de l’architecture logicielle doit être effectuée et documentée afin de s’assurer que toutes les exigences logicielles sont correctement reflétées dans l’architecture globale et que celle-ci prend en charge les interfaces entre les composants. Un tel niveau de vérification n’est tout simplement pas possible sur la base d’une simple image et nécessiterait une représentation détaillée.

Il est donc préférable de considérer l’architecture logicielle comme un document évolutif, sur lequel les développeurs travaillent activement et qu’ils mettent régulièrement à jour.

Ce document doit généralement inclure :

• Un diagramme graphique illustrant les relations entre les composants
• Une description expliquant ce que le diagramme représente
• Une liste des éléments logiciels
• Une liste des composants logiciels externes, également appelés SOUP/OTS
• Des vues architecturales et des niveaux de détail définis

Qu'est-ce que j'entends par vue architecturale ou niveau de détail ?

Il est important de considérer l'architecture logicielle comme un ensemble de diagrammes et de descriptions, et non comme une simple visualisation. Chaque diagramme peut présenter un niveau de détail différent selon ce qu’il représente.

Par exemple, un diagramme peut illustrer une interface vers un composant matériel, un autre peut montrer comment les données sensibles sont séparées dans la base de données, et un autre encore peut décrire comment la communication est chiffrée. Chacun de ces diagrammes répond à des exigences différentes avec le niveau de détail nécessaire.

Chez QMLogic, nous sommes de grands adeptes des documents d’orientation de la FDA car ils fournissent souvent un aperçu plus clair des attentes réglementaires. Nous recommandons de consulter le guide de la FDA «Content of Premarket Submissions for Device Software Functions » (14 juin 2023), en particulier la section E : Diagramme d'architecture système et logicielle.

Conception détaillée du logiciel dans la norme CEI 62304

Une fois que l'on comprend que l'architecture logicielle peut exister à différents niveaux de détail, il devient plus facile de saisir un autre terme de la norme : la conception détaillée du logiciel.

Bien que la norme CEI 62304 ne définisse pas clairement la conception logicielle, le chapitre 5.4, qui traite de ce sujet, montre que l’on peut appliquer les mêmes principes qu’en matière d’architecture logicielle, mais avec plus de profondeur et de précision. En d’autres termes, la conception détaillée du logiciel peut être considérée comme une vue plus détaillée de l’architecture d’un composant logiciel spécifique.

Ne vous attardez donc pas trop à essayer de séparer strictement l’architecture logicielle de la conception détaillée du logiciel. Ils représentent différents niveaux de détail au sein d’un même concept, et il est tout à fait acceptable de les décrire tous les deux dans un seul document.

Vous trouverez des indications supplémentaires dans le document «Content of Premarket Submissions for Device Software Functions» (14 juin 2023), où la FDA désigne ce document sous le nom de SDS (Software Design Specification).

Figure 1 : Spécification de conception logicielle telle que définie par la FDA

Conserver la conception détaillée du logiciel – Implications pour la FDA et la cybersécurité

Selon la norme CEI 62304, un document de conception détaillée du logiciel n’est formellement requis que pour les systèmes de classe de sécurité logicielle C (nous abordons ce sujet plus en détail dans notre article « Comment démarrer la mise en œuvre de la norme CEI 62304 »). Cependant, nous recommandons vivement de conserver un tel document pour plusieurs autres raisons importantes.

Premièrement, la FDA peut demander ce document lors d’une demande d’autorisation de mise sur le marché ou d’une inspection de la FDA.

Deuxièmement, la norme CEI 62304 définit le niveau requis de documentation technique principalement du point de vue de la sécurité des produits. Mais dans le monde actuel des appareils interconnectés et des solutions basées sur le cloud, la cybersécurité est devenue tout aussi cruciale, et la conception logicielle joue désormais un rôle plus important qu’auparavant dans la cybersécurité.

Les normes de cybersécurité, telles que la IEC 81001-5-1, exigent explicitement des activités de conception logicielle comme celles décrites ci-dessous dans des extraits de la norme.

Figure 2 : IEC 81001-5-1 : Conception de l'architecture logicielle

Figure 3 : IEC 81001-5-1 : Conception logicielle

Système logiciel, système et solutions

La signification de système logiciel est assez simple ; elle fait référence à un ensemble d'éléments logiciels (voir la première partie de cette série pour la définition de « élément »).

Cependant, il est important de rappeler que la norme CEI 62304 définit également un système. La norme le décrit comme une combinaison d'éléments en interaction tels que des processus, du matériel, des logiciels et des personnes.

Même si nous pouvons mettre de côté les processus et les personnes pour l'instant, vous ne devez pas négliger le matériel, le stockage de données, l'environnement cloud ou l'infrastructure de communication associés à vos produits logiciels.

D'après mon expérience, ces interfaces ont tendance à être plus évidentes pour les développeurs travaillant sur des logiciels embarqués, mais elles sont souvent négligées dans le développement de plus haut niveau d'un logiciel de dispositif médical autonome.

Pourquoi est-ce important ? Parce que les performances, la disponibilité et la sécurité de votre produit logiciel peuvent toutes être influencées par le système dans lequel il fonctionne. C'est pourquoi il est important de prendre en compte l'ensemble du système, et pas seulement le système logiciel, lors de la réalisation d'activités de test, de gestion des risques ou de cybersécurité.

Vous pourriez également rencontrer le terme Solution. Ce terme n'est pas formellement défini dans la norme et peut être utilisé de différentes manières. Il peut faire référence au même concept qu'un Système, à un ensemble de systèmes définis en interne, ou même à un groupe de dispositifs médicaux différents.

Vous vous épargnerez bien des confusions et des retouches si vous définissez en interne ce que votre organisation entend par « solution ».

SOUP/OTS dans le cycle de vie du logiciel

• SOUP signifie Software of Unknown Provenance (logiciel de provenance inconnue)

• OTS signifie Off-the-Shelf Software (logiciel prêt à l'emploi)

Il y a beaucoup de discussions en ligne pour savoir si SOUP et OTS sont identiques ou différents. Pour faire simple, non, il n’y a pratiquement aucune différence pour vous dans la pratique.

Ces deux termes désignent des composants logiciels qui :

1. N’ont pas été initialement développés pour faire partie d’un dispositif médical, et

1. Ne disposent pas d’une documentation technique complète

La seule différence subtile est que le SOUP pourrait, en théorie, être un logiciel précédemment développé par votre propre organisation, tandis que l’OTS provient généralement d’une source externe.

En réalité, cependant, dans 99,9 % des cas, les termes SOUP ou OTS désignent des logiciels externes intégrés à votre produit, et non quelque chose que votre équipe a développé auparavant. Cette distinction a très peu d’impact pratique sur la manière dont vous gérez les SOUP/OTS, sauf peut-être en matière de cybersécurité, où un logiciel développé en interne (même non documenté) pourrait être considéré comme plus sûr qu’une bibliothèque aléatoire téléchargée sur Internet.

Voici quelques exemples de SOUP/OTS :

• Bibliothèques externes utilisées dans votre logiciel

• Systèmes d'exploitation

• Systèmes de bases de données

• Solutions cloud

• Frameworks de développement backend ou frontend

En résumé, les SOUP et OTS sont des composants logiciels, appelés « éléments logiciels » dans la norme CEI 62304, qui proviennent de l'extérieur de votre organisation.

Pourquoi est-il important d’identifier les SOUP/OTS ?

Les SOUP/OTS représentent des logiciels externes dont dépend votre produit pour sa sécurité, son efficacité et sa sûreté. C’est pourquoi il est essentiel d’identifier ces composants et d’évaluer les risques qui y sont associés.

Vous devriez vous poser des questions telles que :

• Puis-je faire confiance à ce logiciel ?

• Comment puis-je minimiser les risques potentiels qui y sont liés ?

• Que se passerait-il si le SOUP/OTS cessait de fonctionner ?

• Est-il entièrement compatible avec notre système logiciel ?

• Pourrait-il contenir des failles de sécurité, voire des portes dérobées intentionnelles ?

Traçabilité et norme CEI 62304

Le terme traçabilité est défini de manière quelque peu cryptique dans la norme, et son interprétation ainsi que son application pratique ne sont pas toujours claires. La norme CEI 62304 la définit comme « le degré auquel une relation peut être établie entre deux ou plusieurs produits du processus de développement ».

Ici, le terme « produits » ne fait pas référence à votre dispositif médical lui-même, mais plutôt à tout livrable, à tout résultat généré au cours de vos activités de développement. Cela inclut les Design Controls tels que les exigences, l’architecture, les mesures de contrôle des risques et d’autres documents connexes.

En pratique, cela signifie que vous devriez disposer d’un système logique qui relie vos documents et les informations qu’ils contiennent, garantissant que tout reste cohérent et sans contradiction.

Une forme courante de traçabilité utilisée dans la plupart des organisations est le lien entre les exigences, les mesures de contrôle des risques, la conception et la vérification. En termes simples, cela peut ressembler à ceci :

Figure 4 : Traçabilité dans les Design Controls

Cependant, la définition de la traçabilité mentionne également qu’elle inclut l’architecture. Cela nous ramène aux chapitres précédents, où nous avons discuté de ce que signifie réellement l’architecture, et cette compréhension aide à clarifier comment la traçabilité s’applique au sein de l’architecture elle-même.

Comme nous l’avons déjà dit, l’architecture est plus qu’un simple diagramme graphique ; c’est un document complet qui comprend des descriptions et peut également contenir des liens (traçabilité) vers des exigences spécifiques.

Pourquoi la traçabilité est-elle utile ?

Le fait d’avoir des interconnexions claires entre les exigences et l’architecture permet de s’assurer que tous les besoins spécifiques, tels que ceux liés à l’interopérabilité ou à la sécurité, sont correctement pris en compte dans la conception architecturale.

Prenons un exemple. Supposons qu'il existe une exigence d'échange de données chiffrées via Bluetooth entre un périphérique IoT et une application mobile.

Cette exigence doit être visible au sein de l'architecture logicielle :

• L'architecture doit refléter le périphérique IoT.

• L'échange de données entre le périphérique IoT et l'application mobile doit être illustré.

• L'exigence de chiffrement doit être mentionnée dans l'architecture.

• La solution mise en œuvre doit être décrite, y compris les détails concernant le couplage et le comportement de chiffrement.

Grâce à ce type de configuration traçable, si votre responsable, un auditeur externe ou un enquêteur de la FDA vous demande comment les données sont échangées entre le périphérique et l'appareil mobile, vous serez en mesure de présenter une vue d'ensemble complète, transparente et traçable.

Cycle de vie du produit

Bien que la norme elle-même inclue le terme « cycle de vie » dans son titre, ce n’est que maintenant que nous abordons ce concept.

Si la norme CEI 62304 fournit une définition claire du modèle de cycle de vie du développement logiciel, il est tout aussi important de comprendre le concept plus large du cycle de vie du produit.

De nombreuses entreprises ont tendance à associer le cycle de vie du produit principalement aux activités de conception et de développement.

En réalité, cependant, le cycle de vie du produit englobe toute la durée de vie d’un produit médical, depuis son concept initial jusqu’à sa fin de vie. Cette perspective plus large est particulièrement importante pour les logiciels, où la maintenabilité joue un rôle central et permanent.

Pourquoi le cycle de vie du produit est-il important ?

L'environnement entourant les logiciels pour dispositifs médicaux est en constante évolution. Les systèmes d'exploitation évoluent, les infrastructures cloud sont mises à jour, les bibliothèques développent de nouvelles vulnérabilités de sécurité, et les composants logiciels sur lesquels repose votre produit peuvent finir par

devenir incompatibles. Tous ces facteurs doivent être surveillés et gérés après la mise sur le marché de votre produit.

De plus, les données traitées par votre logiciel restent soumises à des exigences réglementaires et de confidentialité tout au long de son utilisation. Au cours de la phase de retrait progressif ou de fin de vie, il est essentiel de disposer de processus définis garantissant qu'aucune donnée médicale sensible ne reste accessible ou stockée de manière inappropriée une fois le produit retiré du marché.

Posez-vous les questions suivantes :

• Que se passe-t-il lorsqu'un utilisateur cesse d'utiliser votre application ?

• Détectez-vous cet événement et disposez-vous de procédures pour identifier et supprimer les données de cet utilisateur ?

• Pouvez-vous confirmer que toutes les données client qui ne sont plus utilisées ont été supprimées de manière sécurisée ?

• Existe-t-il de nouvelles vulnérabilités de sécurité connues dans les composants logiciels que j'utilise ?

• Mon produit est-il compatible avec toutes les versions actuelles des systèmes d'exploitation ?

• Y a-t-il des problèmes dans l'application ou le produit qui n'ont pas été découverts lors des tests mais qui apparaissent en production ?

Ces questions soulignent pourquoi le cycle de vie du produit s'étend au-delà de la conception et du développement.

À l'ère numérique actuelle, ces considérations relatives au cycle de vie sont de plus en plus examinées par les auditeurs et les autorités réglementaires, y compris la FDA.