qualitiso

PRO.CVL

 / Templates / IEC 62304 / PRO.CVL
dernière modification : 26 avril 2019

procédure – Cycle de Vie du Logiciel

Introduction

Une défaillance du logiciel peut potentiellement être critique pour le patient, pour s’en prévenir : la procédure suit la norme IEC 62304, le niveau d’exigence est proportionnel à la classe de dangerosité du logiciel (A, B, C selon la norme).

Attention, ces classes A, B, C sont indépendantes des classes réglementaires Européennes I, IIa, IIb et III. La gestion du cycle de vie du logiciel appelle d’autres processus de la société, notamment :

  • Conception et développement (PRO.C&D)
  • Gestion des risques (PRO.GDR)
  • Évaluation de l’aptitude à l’utilisation (PRO.IAU)
  • Gestion des incidents (PRO.NC-CAPA, PRO.SAV, PRO.VGL)
  • Gestion des modifications (PRO.MDF)
  • Gestion des N.C. (PRO.NC-CAPA)
  • Gestion des documents et enregistrements (PRO.GDD)
  • Communication avec le client et les autorités (PRO.COM)
  • …

Objet

Cette procédure décrit le processus autour du cycle de vie du logiciel (de) DM mis en place par la société. Le processus se décompose en 5 activités :

  1. Gestion des risques
  2. Gestion de la configuration
  3. Développement
  4. Résolution de problème
  5. Maintenance

Destinatires

En fonction de votre organisation

Cette procédure concerne :

  • Equipe de conception, développement, test et maintenance du logiciel.
  • Chef projet
  • Responsable qualité.
  • Responsable gestion des risques
  • Responsable clinique
  • Responsable bureau d’étude
  • Le sous-traitant XXX
  • …

Guides, Normes et Réglementation

  • Règlement (UE) 2017/745
  • IEC 62304 :2006 – cycle de vie des logiciels médicaux + A1 :2015
  • IEC 60601-1 :2007 +A1 :2014

Abréviations

ADR; C&D; CVL; DGR; DDM; E.L.; D.T.; IFU; N.C., PQP; SEMP; SUL; SOUP; U.L.

Définitions

  • blessure grave
    blessure ou maladie qui, directement ou indirectement : menace la vie, ou entraîne une carence permanente d'une fonction physiologique ou endommage de manière définitive une structure du corps, ou nécessite une intervention médicale ou chirurgicale pour prévenir une carence permanente d'une fonction physiologique ou un endommagement définitif d'une structure du corps (IEC 62304:2006)
  • élément de configuration
    entité qui peut être identifiée de manière univoque en un point de référence donné (IEC 62304:2006)
  • élément logiciel
    Toute partie identifiable d’un programme informatique, à savoir: code source, code d'objet, code de contrôle, données de contrôle, ou un ensemble de ces éléments. (IEC 62304)
  • logiciel hérité
    logiciel d'appareil médical ayant été commercialisé légalement, mais pour lequel les preuves objectives de son développement conformément à la version actuelle de la norme manquent (IEC 62304)
  • rapport de problème
    enregistrement du comportement réel ou potentiel d'un PRODUIT LOGICIEL qu'un utilisateur ou une autre personne concernée considère être non sûr, inadéquat pour l'usage prévu ou contraire aux spécifications (IEC 62304:2006)
  • système logiciel
    Ensemble intégré d’éléments logiciels organisés de manière à réaliser une fonction ou un ensemble de fonctions spécifiques. (IEC 62304)
  • unité logicielle
    Élément logiciel qui n'est pas subdivisé en d'autres éléments. (IEC 62304)

▲

Gestion des risques

La gestion des risques se fait conformément à la procédure PRO.GDR. En plus du logiciel (du) dispositif médical, l’analyse des risques est également appliquée aux SOUPs utilisés/embarqués par le dispositif.

Identification des risques dus au logiciel

L’identification des risques dus au logiciel est effectuée en début de développement, elle est affinée au fil des spécifications.

Elle est mise à jour durant toute la vie du dispositif, en fonction des évolutions du contexte. Les risques identifiés sont enregistrés dans le document DOC.AGR. L’identification tient compte des causes potentielles suivantes :

  • Spécification incorrecte ou incomplète de l’E.L. dans la SEL.CVL
  • Défaillance des E.L. internes ou externes
  • Défaillance d’un SOUP
  • Défaillance matérielle
  • Mauvais usage identifié conformément à la procédure IAU
  • …

Classes logicielles associées aux risques

le tableau de définition des classes peut être modifié en fonction de la politique du fabricant en matière d’acceptabilité des risques

Une classe de dangerosité est associés aux risques causés ou maitrisés par le logiciel :

Probabilité Gravité
1 2 3 4
1 A A A A
2 A B C C
3 A B C C
4 A B C C
cet exemple tente un compromis entre classification en fonction de l’accéptabilité et exigences règlementaires ou rien n’est acceptable à priori

Par défaut et avant analyse, le logiciel est traité comme étant de classe C.

Définition des classes

Les risques causés par le logiciel ou maitrisés par le logiciel sont pris en compte pour évaluer la classe. La classe des E.L. est évaluée en fonction de la gravité et de l’accéptabilité des risques :

  • Classe A : pas de risque innacceptable (dommage nul ou proba nulle)
  • Classe B : dommage non grave possible
  • Classe C : dommage grave possible

Évaluation de la classe

Deux cas se présentent pour déterminer la classe de sécurité logicielle :

  • Risques logiciels pour lesquels une mesure de maîtrise non logicielle existe,
  • Risques pour lesquels la mesure de maîtrise de risque est mise en œuvre par le logiciel.

Les risques auxquels le logiciel contribue sont pris en compte après mise en œuvre des mesures de réduction non logicielles, donc en fonction du risque résiduel. Les risques maitrisés par le logiciel sont pris en compte sur la base du risque initial (pas de réduction de la classe de sécurité via le logiciel car le logiciel portant la mesure de maîtrise peut lui-même défaillir).

L’évaluation de la classe du logiciel est enregistrée dans le DOC.DGR, elle s’appuie sur les classe des éléments logiciels enregistrées dans DOC.ADR.

Héritage de la classe de sécurité

La classe de sécurité est attribuée à l’E.L. (ou système logiciel) de plus haut niveau. Les E.L. enfants héritent de la classe de sécurité de leur parent.

Séparation du logiciel et classes de sécurité

Il est possible d’avoir au sein d’un système logiciel des E.L. de classe de sécurité différentes.

Cela est possible au moyen d’une séparation architecturale entre les E.L. de classes différentes.

Le cas échéant, la séparation des E.L. parents/enfants de classes différentes est justifiée et expliquée dans le document SAL.CVL.

Durant le développement : il est autorisé d’appliquer la présente procédure en fonction de la classe de chaque E.L. ; ou d’appliquer systématiquement pour tous les E.L. les exigences de la classe la plus élevée.

Les séparations architecturales communément admises :

  • Entre classe C et B : séparation physique (par exemple 2 micro-contrôleurs séparés physiquement)
  • Entre classe B et A : séparation physique ou logique (par exemple 2 processus communiquant par pipe)

Maitrise de risque par le logiciel

Les mesures de maitrise mises en œuvre par le logiciel (ex : nouvelle spécification en matière d’algorithme, de condition d’alarme, fonction de surveillance, …) sont enregistrées dans le document DOC.ADR, elles constituent de nouvelles entrées à la spécification du logiciel.

▲

Développement

Le développement suit un modèle de cycle de vie en V, les activités à réaliser dépendent de la classe du logiciel :

62304-1

Description du (des) logiciel(s)

Cette section est utile dans certains contextes règlementaires, où une description “macro” du logiciel est demandée : exliquer dans SEL.CLV les principaux aspects techniques, les fonctionnalités et les interactions avec le reste du dispositif.

Données d’entrées

Contenu

En accord avec la procédure de conception & développement PRO.C&D, les données suivantes sont collectées :

  • Spécification système (qui intègre le logiciel)
  • Données relatives à la gestion des risques
  • Données relatives à l’ingénierie de l’aptitude à l’utilisation
  • Exigences réglementaires et normatives
  • Conventions, standards appliqués au développement
  • Etat de l’art : dispositifs comparables, état des technologies, projets en cours, …
  • Le cas échéant : documentation relative aux précédentes versions (dossier technique, revues, évaluations, …)
  • Le cas échéant : données cliniques (étude, rapport de bibliographie, …)
  • Le cas échéant : exigences du client
  • Les normes, méthodes et outils qui sont utilisés pour le développement (à lister dans le PDL).
  • …

Ce contenu est réservé aux abonnés payants.

Laisser un commentaire