La documentation technique d’un dispositif médical est parfois envisagée comme un dossier réglementaire à finaliser avant une soumission ou une évaluation de conformité.
Cette vision est trompeuse.
La documentation technique se construit pendant le développement du dispositif. Elle réunit progressivement les décisions de conception, les preuves de vérification et de validation, les analyses de risques, les données cliniques ou de performances, les informations fournies avec le produit et les activités de surveillance après commercialisation.
Elle doit ensuite rester à jour pendant tout le cycle de vie du dispositif.
Pour une startup ou une petite entreprise MedTech, la difficulté ne consiste donc pas seulement à produire les documents demandés. Il faut également maintenir leur cohérence, leurs liens et leur historique lorsque le produit, les exigences ou les données disponibles évoluent.
Un environnement collaboratif tel que Confluence peut apporter une structure particulièrement utile à ce processus.
La documentation technique n’est pas un ensemble de fichiers indépendants
Les annexes II et III du règlement européen relatif aux dispositifs médicaux (MDR) et du règlement relatif aux dispositifs médicaux de diagnostic in vitro (IVDR) définissent les principaux éléments attendus dans la documentation technique.
Selon la nature du dispositif, celle-ci peut notamment comprendre :
- la description et les spécifications du produit ;
- la destination et les utilisateurs prévus ;
- la qualification et la classification réglementaires ;
- les variantes, accessoires et configurations ;
- les informations de conception et de fabrication ;
- la démonstration de conformité aux exigences générales de sécurité et de performances ;
- le dossier de gestion des risques ;
- les résultats des activités de vérification et de validation ;
- l’évaluation clinique ou l’évaluation des performances ;
- l’étiquetage et les instructions d’utilisation ;
- les informations relatives à la surveillance après commercialisation ;
- les rapports périodiques et les données de vigilance applicables.
Ces éléments ne sont pas indépendants.
Une modification de la destination peut influencer la classification du dispositif, les exigences réglementaires applicables, l’analyse de risques, l’évaluation clinique ou des performances, les spécifications, les tests et l’étiquetage.
De même, une nouvelle information issue d’une vérification, d’une réclamation ou de la surveillance après commercialisation peut entraîner une modification du produit et une mise à jour de plusieurs parties du dossier technique.
Lorsque ces informations sont réparties entre des fichiers Word, des tableurs, des dossiers partagés et des messageries électroniques, les incohérences deviennent difficiles à éviter.
Construire une documentation technique vivante
Une documentation technique maîtrisée devrait permettre de répondre facilement à plusieurs questions :
- Quels documents sont attendus pour ce dispositif ?
- Lesquels sont disponibles, en cours de préparation ou encore à planifier ?
- Quelle version a été revue ou acceptée ?
- Qui est responsable de chaque livrable ?
- Quelles preuves soutiennent chaque exigence réglementaire ?
- Quels risques sont couverts par quelles mesures de maîtrise ?
- Quelles vérifications démontrent que les spécifications sont satisfaites ?
- Quelles parties du dossier doivent être révisées après une modification ?
- Quels documents doivent être transmis à l’organisme notifié ou à une autorité ?
Pour répondre à ces questions, le dossier peut être piloté à l’aide d’un index structuré ou d’une matrice de conformité.
Chaque élément peut recevoir un statut contrôlé, par exemple :
- Planned ;
- In progress ;
- Available ;
- Reviewed ;
- Accepted ;
- Not applicable.
Cette approche permet d’identifier rapidement les livrables manquants, les documents disponibles mais non encore revus et les exclusions qui doivent être justifiées.
L’objectif n’est pas seulement de disposer d’une table des matières. Il s’agit de rendre visible l’état réel de préparation de la documentation technique.
Le socle commun aux dispositifs médicaux et aux IVD
Le MDR et l’IVDR présentent de nombreuses exigences communes en matière de documentation.
Dans les deux cas, le fabricant doit notamment maîtriser :
- la description du dispositif ;
- la destination ;
- la classification ;
- les exigences générales de sécurité et de performances ;
- les risques ;
- la conception et la fabrication ;
- la vérification et la validation ;
- les informations fournies avec le dispositif ;
- la surveillance après commercialisation ;
- les modifications du produit.
La structure du dossier doit toutefois être adaptée à la nature du dispositif et à son stade de développement.
Un produit en phase initiale ne disposera pas encore de toutes les preuves attendues pour une mise sur le marché. Les documents non encore disponibles doivent alors être identifiés et planifiés, sans présenter artificiellement le dossier comme complet.
Au fur et à mesure du développement, l’index de la documentation technique devient ainsi également un outil de pilotage du projet réglementaire.
Les spécificités de la documentation technique IVDR
Pour un IVD, la documentation technique doit intégrer les éléments propres à l’évaluation des performances.
Cela comprend notamment, selon le dispositif :
- la validité scientifique ;
- les performances analytiques ;
- les performances cliniques ;
- le plan et le rapport d’évaluation des performances ;
- les protocoles et rapports d’études ;
- la stabilité ;
- la traçabilité métrologique ;
- les critères d’acceptation ;
- le suivi des performances après commercialisation ;
- les données relatives aux échantillons, calibrateurs et contrôles.
Ces informations proviennent souvent de plusieurs équipes ou partenaires : laboratoire interne, sous-traitants de recherche, fabricants sous contrat, centres cliniques ou partenaires académiques.
Le fabricant doit conserver l’accès aux données sources, aux protocoles, aux résultats complets et aux rapports finaux. Un simple rapport de synthèse transmis par un sous-traitant peut ne pas être suffisant pour démontrer la maîtrise des performances du dispositif.
Une structure documentaire collaborative permet de relier les rapports reçus aux spécifications, aux risques, aux exigences de performances et aux décisions de développement correspondantes.
Les spécificités des logiciels dispositifs médicaux
Pour un logiciel dispositif médical, ou MDSW, la documentation technique doit rester étroitement liée aux activités réelles de développement logiciel.
Selon le produit et les normes appliquées, elle peut notamment comprendre :
- les besoins des utilisateurs ;
- les exigences système et logicielles ;
- l’architecture ;
- les interfaces ;
- la classification de sécurité logicielle ;
- les composants logiciels tiers ;
- les analyses de risques et de cybersécurité ;
- les plans et résultats de tests ;
- la gestion des anomalies ;
- la configuration logicielle ;
- les versions et les notes de publication ;
- les modifications et leur analyse d’impact ;
- les preuves de vérification et de validation.
Le risque principal est de créer une séparation artificielle entre le dossier réglementaire géré par l’équipe qualité et les données opérationnelles utilisées quotidiennement par les développeurs.
L’équipe qualité travaille alors sur des documents statiques, tandis que les développeurs gèrent les exigences, tâches, anomalies, tests et versions dans Jira. À l’approche d’une version réglementaire ou d’un audit, il faut reconstruire les liens entre les deux environnements.
Relier Confluence et Jira pour les projets MDSW
L’intégration entre Confluence et Jira permet de rapprocher la documentation réglementaire du travail quotidien des développeurs.
Dans Confluence, une page décrivant une exigence, une analyse de risque, une version logicielle ou un plan de vérification peut contenir des liens vers les éléments Jira correspondants.
Selon la configuration retenue, il est possible d’afficher dans Confluence :
- un ticket Jira individuel ;
- une liste de tickets répondant à une requête JQL ;
- les anomalies associées à une version ;
- les tâches de vérification encore ouvertes ;
- les actions issues d’une revue de conception ;
- le statut des activités de développement ;
- un tableau de bord ou une chronologie Jira.
Les Smart Links et les macros Jira peuvent afficher dans Confluence des informations actualisées telles que le statut, la priorité ou le responsable d’un élément Jira. Une liste dynamique peut être construite à partir d’une requête JQL et intégrée dans une page de suivi. Atlassian décrit notamment l’affichage de listes de tickets Jira dans Confluence ainsi que l’utilisation des Smart Links entre les produits Atlassian.
Cette intégration peut, par exemple, relier :
- une exigence logicielle à ses tâches d’implémentation ;
- une mesure de maîtrise des risques à son activité de développement ;
- une anomalie à son évaluation de sécurité et à sa correction ;
- un protocole de test aux résultats et anomalies correspondants ;
- une demande de modification aux tickets nécessaires à sa mise en œuvre ;
- une version logicielle aux tâches, anomalies résiduelles et preuves de vérification associées.
Jira reste alors l’outil opérationnel de gestion du développement, tandis que Confluence fournit la structure documentaire, le contexte réglementaire et les éléments devant être revus ou approuvés.
Cette connexion ne crée pas automatiquement la traçabilité réglementaire. L’entreprise doit définir quelles relations sont obligatoires, comment elles sont vérifiées et quelles informations doivent être figées ou exportées pour chaque version du dispositif.
Les avantages de Confluence pour la documentation technique
Des liens actifs entre les documents
Les pages peuvent être reliées entre elles : procédure, formulaire, exigence, risque, rapport de test, évaluation clinique, décision de conception ou modification.
Cette navigation réduit la dépendance à une arborescence de fichiers et permet de retrouver plus facilement le contexte d’une information.
Un historique des versions
Confluence conserve l’historique des modifications apportées aux pages. L’équipe peut comparer les versions et identifier l’évolution du contenu.
Cet historique doit être complété par des règles définissant les versions réglementairement approuvées, les responsabilités et les enregistrements à conserver.
La réutilisation de contenus communs
La fonction Excerpt permet de maintenir un texte source et de l’afficher dans plusieurs pages.
Elle peut être utilisée, avec prudence, pour des informations communes telles que :
- la description du dispositif ;
- la destination ;
- les coordonnées du fabricant ;
- certaines définitions ;
- une liste contrôlée de variantes.
Une modification apportée à la source est alors répercutée dans les pages qui utilisent cet extrait. Cela peut limiter les divergences entre plusieurs parties du QMS ou de la documentation technique.
L’utilisation de ce mécanisme doit néanmoins être contrôlée : une modification commune peut avoir un impact sur plusieurs documents et doit donc être soumise à une analyse appropriée.
Des tableaux pour les informations structurées
Certaines informations sont mieux gérées sous forme de tableau que dans un document narratif :
- index de la documentation technique ;
- matrice de conformité aux exigences générales de sécurité et de performances ;
- matrice de traçabilité ;
- tableau de gestion des risques ;
- liste des composants logiciels ;
- suivi des vérifications et validations ;
- registre des modifications.
Des applications de type spreadsheet peuvent compléter Confluence lorsque des fonctions comparables à celles d’un tableur sont nécessaires.
Des approbations et signatures électroniques
Des applications disponibles dans l’écosystème Atlassian peuvent ajouter des workflows de révision, d’approbation et de signature électronique.
Le choix et la configuration de ces applications doivent correspondre aux exigences du fabricant. Leur utilisation peut également nécessiter une validation proportionnée à leur usage prévu.
Des exports destinés aux organismes externes
Une page Confluence peut être exportée au format PDF. Un espace ou un ensemble structuré de pages peut également être préparé pour constituer un dossier transmissible à un organisme notifié, une autorité ou un partenaire.
L’environnement collaboratif reste ainsi la source de travail, tandis que des versions contrôlées peuvent être générées pour les évaluations externes.
Avant transmission, l’entreprise doit vérifier la complétude de l’export, les liens, les pièces jointes, l’identification des versions et la confidentialité des informations.
ReadySet : relier le QMS et la documentation technique
ReadySet for Confluence fournit une structure destinée à organiser les processus qualité et réglementaires d’un fabricant de dispositifs médicaux.
Cette structure peut notamment couvrir :
- le contrôle des documents et enregistrements ;
- la conception et le développement ;
- la gestion des risques ;
- la documentation technique ;
- la gestion des fournisseurs ;
- les modifications ;
- les non-conformités et CAPA ;
- l’évaluation clinique ou des performances ;
- la surveillance après commercialisation ;
- les audits et revues de direction.
Des versions adaptées aux dispositifs médicaux, aux IVD et aux logiciels dispositifs médicaux sont disponibles.
ReadySet permet ainsi de rapprocher le QMS et le dossier technique dans un même environnement. Les procédures définissent comment les activités sont maîtrisées, tandis que les formulaires, matrices et pages du dossier technique recueillent les preuves produites pendant le développement et le cycle de vie du dispositif.
Pour les équipes MDSW utilisant Jira, cette structure peut être reliée aux tâches, anomalies, tests et versions gérés par les développeurs.
ReadySet fournit une structure, pas une conformité automatique
ReadySet ne transforme pas automatiquement Confluence en système conforme et ne garantit pas qu’une documentation technique soit complète ou acceptable pour une autorité ou un organisme notifié.
Chaque fabricant reste responsable :
- de déterminer les exigences applicables ;
- d’adapter la structure à son dispositif et à ses marchés ;
- de produire les preuves nécessaires ;
- de définir les responsabilités ;
- d’approuver les documents ;
- de contrôler les modifications ;
- de maintenir la traçabilité ;
- de valider les outils informatisés lorsque cela est nécessaire ;
- de vérifier la complétude du dossier avant une soumission.
ReadySet constitue une base structurée destinée à faciliter ce travail et à éviter que la documentation technique ne soit reconstruite tardivement à partir de fichiers dispersés.
Conclusion
La documentation technique MDR ou IVDR ne devrait pas être constituée uniquement à l’approche d’une soumission ou d’un audit.
Elle doit accompagner le développement du dispositif et évoluer avec les exigences, les risques, les résultats de vérification et de validation, les données cliniques ou de performances et les informations post-commercialisation.
Confluence peut fournir un environnement collaboratif dans lequel ces éléments restent organisés et reliés. Pour les logiciels dispositifs médicaux, l’intégration avec Jira permet également de rapprocher le dossier réglementaire des activités réelles de développement.
ReadySet for Confluence fournit une structure conçue pour aider les équipes MedTech à établir cette continuité entre QMS, développement et documentation technique.
Vous souhaitez découvrir comment ReadySet peut être adapté à votre dispositif médical, votre IVD ou votre logiciel dispositif médical ?
Contactez AZ Biotech Consulting pour obtenir davantage d’informations ou organiser une présentation de ReadySet for Confluence.