Logiciels de vigilance DM : trois solutions pour la conformité

Logiciels de vigilance DM: trois solutions pour la conformité

Il tombe à deux jours en cas de menace grave pour la santé publique et s’établit à quinze jours pour les autres incidents graves. Ces délais ne commencent pas au moment où le dossier est parfaitement documenté: ils s’inscrivent dans une chaîne qui débute avec la réception d’une réclamation ou d’un signal pertinent, puis se poursuit avec son évaluation, sa qualification et, si nécessaire, sa notification à l’autorité compétente.

Pour un fabricant qui commercialise un dispositif médical de classe IIb ou III, le problème n’est donc pas seulement de remplir un formulaire. Il faut être capable de retrouver l’origine du signal, d’identifier le dispositif concerné, de documenter la décision de déclarabilité, de suivre les échanges avec les autorités et de relier l’événement aux actions correctives, à l’analyse des tendances et au suivi après commercialisation. Un retard ou une décision impossible à reconstituer fragilise le dossier de vigilance autant qu’une erreur dans le formulaire lui-même.

C’est dans cet espace que se positionne le logiciel de gestion de la vigilance des dispositifs médicaux. Veeva Vault Product Surveillance, TrackWise Digital Post-Market Surveillance et Greenlight Guru Complaint Management proposent trois réponses assez différentes: plateforme qualité d’entreprise, automatisation du reporting ou gestion spécialisée des réclamations. Aucun de ces outils ne transforme mécaniquement un fabricant en organisation conforme au RDM. Leur valeur dépend de la qualité du système qualité dans lequel ils sont déployés, des règles qu’on leur fait appliquer et de la capacité des équipes à contrôler leurs résultats.

Les impératifs réglementaires du RDM: au-delà de la simple déclaration

Le règlement (UE) 2017/745 a élargi la vigilance bien au-delà de la notification d’un incident grave. La surveillance après commercialisation doit alimenter un dispositif continu de collecte, d’analyse et de réévaluation. Le fabricant doit pouvoir relier les réclamations, les incidents, les données cliniques, les actions correctives et les évolutions du profil de risque du dispositif.

Dans la pratique, le flux de vigilance croise plusieurs processus du système de management de la qualité:

• réception et enregistrement des réclamations;
• identification du dispositif, du lot, du numéro de série ou de la version logicielle concernés;
• évaluation médicale et réglementaire de l’événement;
• détermination du caractère grave ou non de l’incident;
• décision de notifier ou de ne pas notifier, avec justification;
• notification à l’autorité compétente et suivi des demandes complémentaires;
• lancement éventuel d’une investigation, d’une CAPA ou d’une action corrective de sécurité;
• intégration des résultats dans le dossier PMS et, lorsque cela s’applique, dans le PSUR;
• analyse des tendances et réévaluation du risque.

Une réclamation ne devient pas automatiquement un incident grave. Mais une réclamation qui ne relève pas de la notification doit tout de même laisser une trace exploitable dans le système qualité. Cette distinction est importante, car les outils ne traitent pas seulement des événements déclarables. Ils doivent aussi conserver les événements écartés, les raisons de l’écartement et les éventuels éléments nouveaux susceptibles de faire évoluer la décision.

La guidance MDCG 2023-3 a précisément contribué à clarifier le lien entre réclamations, incidents et tendances. Les formulations employées dans les procédures internes ne suffisent pas: l’entreprise doit pouvoir montrer comment elle applique ses critères à des situations concrètes. Une douleur signalée par un patient, une défaillance observée par un professionnel de santé ou une série de retours similaires ne seront pas nécessairement traitées de la même manière. Le contexte clinique, les conséquences réelles ou potentielles et les informations disponibles au moment de l’évaluation comptent tous.

Un logiciel de vigilance ne garantit pas la conformité au RDM: il structure le flux de travail. La conformité naît de la combinaison entre l’outil, les procédures documentées, la validation du logiciel et la compétence de l’équipe.

Le dispositif doit également être raccordé aux obligations françaises. Le fabricant doit organiser la matériovigilance, désigner les responsabilités appropriées et maintenir des canaux opérationnels avec l’ANSM et les autres autorités compétentes concernées par son périmètre de commercialisation. Les formats et les modalités de transmission peuvent différer selon le territoire et selon le niveau de déploiement des systèmes européens. Une plateforme internationale capable de produire un rapport au format attendu par une autorité ne dispense donc pas de vérifier le circuit effectivement applicable en France.

Cette vérification doit porter sur des éléments très concrets: qui reçoit la tâche, qui peut modifier la qualification, qui valide la notification, quelle preuve est conservée, comment une correction est enregistrée et comment les délais sont calculés. Un compteur de délai n’a de valeur que si son point de départ est défini par la procédure et si les données d’entrée sont fiables.

Veeva Vault Product Surveillance: l’approche par workflows configurables

Veeva Vault Product Surveillance s’inscrit dans la plateforme Vault Quality. Son intérêt principal tient à cette continuité avec les autres processus documentaires et qualité: gestion des documents, formation, CAPA, changements et approbations peuvent être organisés dans un environnement commun. L’outil vise donc moins le simple registre de réclamations qu’un flux complet de surveillance après commercialisation.

Le principe est celui de workflows configurables. Une réclamation est enregistrée, affectée à un responsable, soumise à une séquence d’évaluation puis orientée vers les étapes prévues par la procédure. Les notifications, les escalades et les tâches en retard peuvent être paramétrées selon les règles de l’organisation. Cette logique est particulièrement utile lorsque plusieurs sites, pays ou unités commerciales transmettent des informations au même service de vigilance.

Ce que l’approche par workflow change réellement

Dans une organisation internationale, l’enjeu n’est pas uniquement de centraliser les dossiers. Il faut aussi éviter que deux équipes appliquent des règles différentes à des événements comparables. Veeva met en avant la possibilité de configurer des arbres de décision et des règles par pays. Sur le papier, cette approche permet de distinguer les exigences de différents marchés tout en conservant un dossier source commun.

Le bénéfice dépend toutefois de la gouvernance du paramétrage. Un arbre de décision ne constitue pas une interprétation réglementaire autonome. Il traduit une procédure écrite dans une suite de questions et d’orientations. Si cette procédure est incomplète, si les termes sont ambigus ou si les responsabilités ne sont pas définies, le workflow reproduira ces faiblesses avec une apparence de cohérence.

L’intégration avec la documentation qualité est le point fort le plus évident. Une investigation peut être reliée à une CAPA, à une modification de conception, à une mise à jour d’un rapport PMS ou à une nouvelle version d’une procédure. La traçabilité est alors plus facile à maintenir que dans une succession de fichiers séparés et de boîtes aux lettres partagées.

Pour quel environnement?

Vault Product Surveillance correspond surtout à des fabricants qui disposent déjà d’une organisation qualité structurée et qui recherchent une plateforme commune pour plusieurs processus. L’investissement se justifie davantage lorsque la vigilance doit être coordonnée entre de nombreux produits, plusieurs marchés et plusieurs équipes que lorsque le volume de réclamations reste faible et traité par un service restreint.

La contrepartie est connue: une plateforme d’entreprise demande une phase de conception, de configuration, de migration et de validation conséquente. Il faut également prévoir la gouvernance du système après le déploiement. Les règles de déclarabilité, les formulaires, les rôles et les interfaces évoluent; un workflow laissé sans maintenance devient rapidement une photographie d’une procédure ancienne.

Les informations publiques de l’éditeur ne permettent pas, à elles seules, de conclure à une intégration native avec les procédures françaises de déclaration auprès de l’ANSM. Ce point doit être vérifié dans le périmètre exact du projet, avec les formats utilisés par le fabricant et les scénarios de retour d’information attendus des autorités.

TrackWise Digital: automatisation et reporting réglementaire intégré

TrackWise Digital, développé par Sparta Systems au sein de Honeywell, s’appuie sur une logique d’eQMS plus large. Son module de surveillance après commercialisation couvre la réception et l’investigation des réclamations, l’évaluation de la déclarabilité, les actions correctives, l’analyse des tendances et le reporting réglementaire.

L’orientation de la solution est assez lisible: réduire les ruptures entre le dossier interne et le rapport destiné à l’autorité. La prise en charge annoncée de formats tels que l’eMDR américain et le formulaire européen de rapport d’incident constitue un argument pour les fabricants présents sur plusieurs marchés. Elle peut limiter la ressaisie, à condition que les données recueillies au départ soient suffisamment complètes et correctement structurées.

L’automatisation du reporting n’est pas une validation réglementaire

La génération d’un rapport à partir d’un dossier existant apporte un gain opérationnel évident. Elle réduit les erreurs de transcription et facilite le suivi des versions. Mais elle ne répond pas à la question centrale: les informations initiales sont-elles exactes, et la qualification de l’événement est-elle défendable?

Le logiciel peut signaler qu’un délai approche, créer une tâche d’escalade ou préparer un formulaire. Il ne peut pas déterminer seul si une dégradation fonctionnelle est grave dans le contexte clinique du patient, ni apprécier toutes les conséquences possibles d’une défaillance. L’automatisation de la vigilance réglementaire doit donc être conçue comme une assistance contrôlée, non comme une délégation de l’analyse.

TrackWise peut être pertinent pour une entreprise qui souhaite faire converger la vigilance avec les CAPA, les non-conformités et les actions d’amélioration. Dans ce type d’environnement, la question n’est pas seulement « l’incident a-t-il été déclaré? », mais aussi « qu’a-t-il changé dans le système? ». Une tendance détectée dans les réclamations peut conduire à une investigation fournisseur, à une revue de conception ou à une modification des instructions d’utilisation.

L’évaluation de la déclarabilité est le nœud critique: une erreur dans l’arbre de décision se propage dans chaque notification, chaque PSUR et chaque interaction avec l’autorité compétente.

Une solution adaptée aux organisations déjà équipées

TrackWise Digital s’adresse d’abord aux organisations qui ont déjà un socle qualité mature et des processus relativement formalisés. Le bénéfice de l’outil sera limité si les données produit sont dispersées, si les rôles de validation ne sont pas stabilisés ou si les équipes ne partagent pas la même définition d’une réclamation.

Le reporting multi-format doit également être examiné avec prudence. La présence d’un format dans la présentation produit ne signifie pas que tous les cas français ou européens seront couverts sans adaptation. Il faut vérifier les champs obligatoires, les règles de transformation des données, la gestion des pièces jointes, la conservation des échanges et la possibilité de documenter une soumission corrigée.

Comme pour les autres plateformes de niveau entreprise, les éléments publics ne suffisent pas à comparer objectivement le coût, le délai de déploiement, la validation, la cybersécurité ou le traitement des données personnelles. Ces sujets doivent être instruits pendant la qualification du fournisseur, puis dans la validation de la configuration réellement déployée.

Greenlight Guru: gestion des réclamations et traçabilité documentaire

Greenlight Guru adopte un positionnement plus spécialisé. La plateforme est conçue pour les fabricants de dispositifs médicaux et met l’accent sur la cohérence entre les activités qualité, les dossiers produit et la gestion des réclamations. Son module Complaint Management vise à documenter les événements, leur évaluation, l’investigation et la décision qui en découle.

Cette spécialisation peut être attractive pour une PME qui ne souhaite pas paramétrer une plateforme généraliste conçue pour plusieurs secteurs réglementés. Le vocabulaire, les objets qualité et les relations entre les dossiers sont plus proches des usages d’un fabricant de DM. Cela ne supprime pas le travail de configuration, mais peut réduire la distance entre l’outil et les procédures internes.

Une réponse centrée sur la réclamation

Le point fort de Greenlight Guru est la traçabilité du dossier de réclamation. Les informations peuvent être réunies au même endroit: description du problème, dispositif concerné, évaluation de la gravité, décision de déclarabilité, pièces justificatives et tâches d’investigation. La conservation de cette décision est essentielle lors d’un audit. Une absence de notification doit pouvoir être expliquée aussi clairement qu’une notification effectivement transmise.

L’outil peut également aider à répartir les responsabilités entre qualité, affaires réglementaires, ingénierie et service client. Cette répartition est loin d’être secondaire. Les premiers signaux arrivent souvent par des canaux qui ne relèvent pas directement de la vigilance: support technique, distributeur, commercial ou retour d’un utilisateur. Le système doit transformer cette information informelle en dossier contrôlé sans perdre son contexte.

La limite apparaît lorsque l’entreprise attend une couverture très large du cycle PMS et des soumissions internationales. Le module est principalement présenté autour de la gestion des réclamations et de la documentation de leur traitement. Les informations publiques disponibles ne permettent pas d’établir une équivalence avec les fonctions annoncées par Veeva ou TrackWise en matière d’arbres de décision multi-pays, d’analyse des tendances et de reporting réglementaire intégré.

Le choix de la simplicité, avec ses conséquences

Pour une structure de taille modeste, une solution plus ciblée peut être préférable à une plateforme surdimensionnée. Encore faut-il que le périmètre retenu corresponde au besoin réel. Si l’entreprise veut relier automatiquement les réclamations aux tendances PMS, aux PSUR, aux CAPA et aux données cliniques, elle devra examiner les fonctions disponibles, les interfaces et les éventuels modules complémentaires.

La couverture des formats européens doit faire l’objet d’une démonstration spécifique. La capacité à préparer un rapport destiné à la FDA ne permet pas de déduire une automatisation équivalente pour les procédures européennes ou françaises. Le fabricant doit demander à voir un scénario complet, depuis la réception d’une réclamation jusqu’à l’archivage de la décision et des échanges avec l’autorité.

Comparatif fonctionnel des trois solutions

Le tableau ne désigne pas un gagnant universel. Il met plutôt en évidence le niveau auquel chaque solution intervient. Veeva est cohérent avec une stratégie de plateforme unifiée; TrackWise privilégie la continuité entre qualité, vigilance et reporting; Greenlight Guru part de la réclamation et de sa traçabilité dans un environnement exclusivement orienté dispositifs médicaux.

Limites de l’automatisation: pourquoi le logiciel ne remplace pas le système qualité

Le premier piège consiste à confondre une fonction disponible et une conformité démontrée. Un fournisseur peut annoncer un workflow configurable, un formulaire réglementaire ou une analyse automatisée des tendances. Le fabricant reste responsable de la manière dont ces fonctions sont configurées, utilisées, contrôlées et validées dans son propre système qualité.

La validation doit couvrir le logiciel tel qu’il est réellement déployé, et non une démonstration générique. Les règles de calcul des délais, les droits d’accès, les changements de statut, les signatures électroniques, les journaux d’audit, les interfaces avec les autres systèmes et les exports doivent être testés. Une plateforme robuste peut devenir non maîtrisée après une modification de workflow non documentée ou une migration de données mal contrôlée.

Les référentiels applicables dépendent du contexte de l’entreprise et de son périmètre d’activité. L’Annexe 11 et le 21 CFR Part 11 peuvent notamment entrer en jeu pour les systèmes informatisés utilisés dans des environnements réglementés, mais leur présence dans une présentation commerciale ne constitue pas une preuve de conformité du déploiement. De la même manière, la certification ISO 13485 concerne le système de management de la qualité de l’organisation; elle ne « certifie » pas automatiquement le logiciel utilisé par le fabricant.

Le RGPD demande lui aussi une analyse séparée. Les réclamations peuvent contenir des données relatives à la santé, des coordonnées de professionnels ou d’utilisateurs et des informations permettant de relier un événement à une personne. Le fabricant doit donc définir les finalités, les habilitations, les durées de conservation, les règles de minimisation et les modalités d’accès aux dossiers. Une plateforme internationale ne dispense pas d’établir cette gouvernance.

Le second piège est de croire que l’automatisation résout la qualité des données. Un dossier de vigilance mal renseigné restera mal renseigné, même si le logiciel le transmet rapidement. Les champs obligatoires peuvent empêcher une clôture prématurée, mais ils ne vérifient pas toujours la pertinence clinique d’une réponse ou la cohérence d’un récit d’événement. La qualité se joue en amont: formation du service client, consignes aux distributeurs, formulaire de réception, règles d’escalade et disponibilité des experts.

Le troisième piège concerne les tendances. Détecter une hausse de réclamations suppose de comparer des événements homogènes. Il faut tenir compte des volumes distribués, des périodes d’utilisation, des changements de produit, des différences de population et des variations dans la qualité de la remontée d’information. Un outil peut regrouper des dossiers et produire un signal; il ne décide pas seul si ce signal traduit une évolution du risque ou un changement dans la manière de collecter les données.

Le fabricant doit enfin conserver une capacité de fonctionnement en cas d’indisponibilité du logiciel. Les procédures de continuité, les droits d’accès d’urgence, les sauvegardes et la reprise des événements reçus hors système sont rarement les éléments les plus visibles lors d’une démonstration commerciale. Ils deviennent pourtant essentiels lorsqu’un délai réglementaire continue de courir alors que l’outil n’est pas accessible.

Le logiciel accélère le flux. Il ne remplace ni l’expertise réglementaire ni la validation du système qualité. Choisir l’un sans l’autre, c’est automatiser le risque.

Quel choix pour quel fabricant?

Veeva Vault Product Surveillance est le choix le plus cohérent pour une organisation qui veut inscrire la vigilance dans une plateforme qualité globale. Son intérêt augmente lorsque les équipes travaillent sur plusieurs marchés, que les processus sont nombreux et que la traçabilité doit relier les événements aux CAPA, aux documents contrôlés et aux activités PMS. En contrepartie, le projet exige une gouvernance solide et une capacité à maintenir une configuration complexe.

TrackWise Digital convient aux fabricants qui recherchent une articulation étroite entre surveillance après commercialisation, qualité et reporting réglementaire. Sa prise en charge annoncée de plusieurs formats peut intéresser les entreprises présentes aux États-Unis et en Europe. Le point à examiner n’est pas seulement la liste des formats disponibles, mais la façon dont ils sont alimentés, revus, corrigés et archivés dans le processus réel.

Greenlight Guru peut mieux répondre à une PME de dispositifs médicaux qui veut d’abord fiabiliser la gestion des réclamations et la conservation des décisions. Sa spécialisation sectorielle peut faciliter l’appropriation par les équipes. Elle doit toutefois être confrontée aux besoins à moyen terme: analyse des tendances, production des rapports PMS, PSUR, gestion de plusieurs juridictions et intégration avec les outils déjà utilisés.

Avant de retenir un outil de conformité post-market surveillance, il est préférable de le tester sur des cas représentatifs plutôt que sur une démonstration idéale. Le scénario devrait inclure une réclamation incomplète, un incident potentiellement grave, une demande d’information complémentaire, une décision de non-notification, une série d’événements similaires et une action corrective. Il faut ensuite vérifier si chaque étape est traçable et si les délais, les responsabilités et les preuves documentaires restent visibles.

Le choix peut être résumé autour de quelques questions opérationnelles:

• Le système permet-il de distinguer clairement réception, évaluation, investigation, notification et clôture?
• La décision de déclarabilité est-elle justifiée et modifiable uniquement par les personnes autorisées?
• Les règles de délai sont-elles configurables selon le type d’événement et le territoire concerné?
• Les pièces jointes, échanges et versions successives sont-ils conservés dans un audit trail exploitable?
• Les données de vigilance peuvent-elles alimenter les tendances, le PMS et les CAPA sans ressaisie inutile?
• Le fabricant peut-il démontrer la validation de sa configuration et la maîtrise des changements?
• Les procédures françaises, notamment les échanges avec l’ANSM, sont-elles réellement couvertes ou seulement évoquées dans la documentation commerciale?

Le meilleur logiciel de gestion de la vigilance des dispositifs médicaux n’est donc pas celui qui promet le plus haut degré d’automatisation. C’est celui dont le fonctionnement correspond aux procédures approuvées, aux compétences disponibles et au périmètre réglementaire du fabricant. Veeva, TrackWise et Greenlight Guru peuvent chacun structurer une partie importante du dispositif de vigilance. Aucun ne peut, à lui seul, décider à la place de l’organisation ce qui doit être déclaré, démontrer la pertinence clinique d’une évaluation ou corriger une procédure défaillante.

La conformité au règlement 2017/745 se construit dans cet écart entre l’outil et son usage. Le logiciel réduit les ruptures de flux, rend les responsabilités visibles et facilite la reconstitution des décisions. Le système qualité, lui, donne un sens réglementaire à ces traces. C’est leur cohérence — et non le nom de la plateforme — qui sera examinée lorsque le dossier devra résister à un audit ou à une question de l’autorité compétente.