Dispositifs médicaux

De nombreuses entreprises consacrent beaucoup de temps non seulement à remplir la documentation pendant le processus de conception, mais aussi à la stocker, la récupérer, obtenir les autorisations nécessaires, passer par le processus d’approbation et mettre à jour le statut du projet. En outre, cette activité prend beaucoup de temps, non seulement lors de la création et du stockage de la documentation, mais aussi lorsque vous devez la récupérer.

Les entreprises passent beaucoup de temps à rechercher les documents corrects à récupérer. En effet, la plupart des solutions disponibles sur le marché ne sont pas adaptées aux spécificités de l’industrie des dispositifs médicaux. Le processus n’est que partiellement couvert, ce qui entraîne des mises à jour manuelles de la documentation, des enregistrements manuels et la conversion des documents, ce qui augmente le risque d’erreurs, la charge de travail et le manque de visibilité.

Dans cette vidéo, je vais vous montrer comment vous pouvez gérer la documentation d’un projet qui n’est pas sur la bonne voie afin d’obtenir un statut de projet précis et à jour. Récupération plus rapide de la documentation, meilleure visibilité et réduction du risque d’erreurs. Le système indiquera les livrables exacts qui ne sont pas sur la bonne voie, ce qui signifie que vous serez en mesure de récupérer la bonne documentation dès la première fois.

Lorsque vous apportez des modifications et des révisions à la documentation, le système en assure automatiquement le suivi et les enregistre. Cela garantit que tout le monde travaille sur la dernière révision. Le système est également capable de convertir automatiquement la documentation dans d’autres formats de fichiers tels que PDF. Enfin, lorsqu’un nouveau livrable est marqué comme prêt, la personne chargée de valider la modification est automatiquement alertée lorsque tout le monde a terminé son travail afin de garantir que le livrable est terminé, la phase est automatiquement terminée et tout le monde peut passer à l’étape suivante. Lorsque Mike arrive au travail, la première chose qu’il fait est de se connecter à Minerva PLM. Une fois dans le système, Mike souhaite vérifier l’état d’avancement de ses projets. Il se rend donc dans la section « Projets » et constate que le projet PB 560 concernant le ventilateur est en retard.

Il ouvre le projet pour savoir pourquoi ce projet est en retard et charge la matrice des livrables. Dans cette matrice, il peut clairement voir le statut de tous les livrables. Il constate qu’il a deux livrables en retard. Vous pouvez également voir que l’un d’eux a une règle de clôture par propriétaire et l’autre par une version de livrable. La règle de clôture pour la liste des pays et les exigences linguistiques est le livrable de Mike, il peut donc le clôturer en appuyant sur le bouton « Clôturer ».

Cela sera enregistré, indiquera au système que Mike a terminé et le statut de ce livrable sera automatiquement défini sur « fermé ». L’autre livrable qui n’est pas terminé est le document des exigences client pour la carte de buzzer. Il s’agit d’un document Word qui doit être fermé par un ECO. Mike ouvre Word via le connecteur Office.

Il recherche ce fichier spécifique dans la base de données Aras. Il le trouve et peut maintenant l’ouvrir pour le modifier. Word charge automatiquement le fichier depuis Aras et Mike peut y accéder et terminer ce document. Il ajoute que ce document doit également être valable pour le modèle ventilé PB 560, puis il met à jour la table des matières, car l’historique des révisions n’est plus nécessaire dans ce document, puisqu’il est désormais contrôlé par le système PLM. Il enregistre ce document dans Aras. Cela met à jour le fichier dans Aras et génère automatiquement un fichier PDF qui peut être consulté dans le système. Une fois le document enregistré, une notification est envoyée dans Word. Il peut revenir en arrière, ouvrir l’objet document, cliquer sur la barre latérale pour charger le fichier consultable et vérifier que ses modifications ont bien été intégrées au fichier. Il fait défiler la page vers le bas et constate que la table des matières a été mise à jour, que l’historique des révisions n’apparaît plus et que sa mise à jour indiquant que ce document doit également couvrir la série de ventilateurs PB 560 a bien été intégrée.

En revenant au formulaire principal du document, Mike peut aller dans l’onglet Modifications pour voir l’état du processus de publication de ce document. Il trouve une relation avec l’ordre de modification du document à publier, voit qu’il lui est attribué, et Mike peut maintenant valider le processus de publication, publiant ainsi le document, ce qui clôturera également la dernière ligne de livrable qui était en retard dans son projet. Le document est maintenant publié. Mike peut revenir à son projet, actualiser sa matrice de livraison et constater que le dernier livrable en retard est désormais clôturé. S’il revient en arrière et recherche à nouveau ses projets, il constate que tout est en ordre.

Tous les projets sont en bonne voie et il peut poursuivre sa journée.

La capture du fichier d’historique de conception et de la fiche de base du dispositif sont deux exemples de structures de documents exigées par les organismes de réglementation. Ils sont associés à un dispositif ou à un produit, et nous devons être en mesure de saisir les modifications qui y sont apportées. Dans de nombreux cas, cela peut être une tâche manuelle fastidieuse. Il est donc indispensable pour toute solution destinée à l’industrie des dispositifs médicaux de disposer d’un système permettant de créer facilement autant de structures réglementaires que vous souhaitez gérer et de les gérer de la même manière afin qu’elles soient automatiquement créées, automatiquement suivies et automatiquement référencées. Plusieurs de nos clients constatent qu’il existe d’autres structures de documentation, telles que le dossier technique, qui doivent également être gérées de la même manière que les DHF et les DMR. Il est essentiel de disposer d’un moyen simple de créer de nouvelles structures de données documentaires telles que les DHF et les DMR, qui ont les mêmes exigences en matière de gestion des modifications et de traçabilité, afin de pouvoir répondre non seulement à vos besoins immédiats, mais aussi à vos besoins futurs.

Dans une société, l’équipe travaille à la conception d’un nouveau ventilateur respiratoire. Comme vous pouvez l’imaginer, le développement d’un tel équipement est un projet très complexe et il est crucial de disposer d’une traçabilité complète de ce qui a été fait par qui et de ce qui a été modifié, non seulement pour commercialiser plus rapidement les ventilateurs, mais aussi pour obtenir les autorisations requises auprès des organismes de réglementation. Dans cette société, les changements de projet ne sont plus un cauchemar. Mike et son équipe travaillent d’arrache-pied pour mener à bien le projet de ventilateur, mais pendant la phase de conception, ils se rendent compte qu’ils ne pourront pas terminer le dépôt du brevet avant la fin de cette phase et souhaitent passer à la phase suivante, qui consiste à concevoir un prototype.

Pour effectuer un tel changement dans Minerva PLM, il est nécessaire de créer un ordre de modification appelé « modification de conception ». Cela permet de conserver la piste d’audit et la traçabilité des modifications apportées. Ces modifications peuvent être créées automatiquement à partir de la section « Modifications » du projet en cliquant sur le bouton « Modification de conception ». Cela crée automatiquement l’ordre de modification, que Mike peut désormais automatiquement consulter et approuver pour passer à l’étape suivante.

Le fait d’arriver à cette étape de travail crée une nouvelle révision. Comme nous pouvons le voir, la révision passe de D à E et est désormais en cours, ce qui signifie que Mike peut accéder au projet et le modifier. C’est ce qu’il fait. Il identifie le livrable « dépôt de brevet », clique avec le bouton droit de la souris, coupe ce livrable, le déplace vers le prototype d’ingénierie et le colle dans cette phase. En cliquant sur « Enregistrer », ce livrable passe de la phase de conception à celle de prototype d’ingénierie. Comme nous pouvons le voir ici, il se trouve désormais dans la phase de prototype d’ingénierie du projet. Le projet est toujours en cours, ce qui signifie que cette modification n’a pas encore été acceptée. Pour que cela soit accepté, Mike doit soumettre cette modification de conception à une étape de révision au cours de laquelle le groupe de pilotage peut évaluer les modifications proposées et décider de les accepter ou non.

Mike se connecte donc et envoie cette modification pour révision. Il peut ajouter un commentaire. En raison du temps disponible, nous souhaitons passer à la phase suivante du dépôt du brevet. Lorsqu’il clique sur Terminé, une notification est envoyée à l’ensemble du groupe de pilotage pour l’informer qu’une demande de modification a été soumise par Mike afin de déplacer ce livrable. Les membres du groupe peuvent désormais évaluer cette modification et donner leur avis, qu’ils souhaitent l’approuver ou non.

En attendant, Mike ne peut que patienter. Au bout d’un certain temps, Mike est informé que le groupe de pilotage a approuvé ses modifications. Lorsqu’il accède à son projet, il constate que la révision E est désormais publiée. Lorsqu’il passe à son projet, il constate que le dépôt du brevet ne fait plus partie de la phase de conception, mais a été déplacé vers la phase de prototype technique.

Cela donne donc à l’équipe un peu plus de temps pour terminer la phase de conception et faire tout ce qui doit être fait. Pour des raisons de traçabilité, toutes les versions et toutes les bases de référence sont toujours conservées dans le système. Ainsi, si quelqu’un souhaite vérifier, nous pouvons maintenant voir qu’il s’agit de la révision E, quel était le statut de la révision D de ce projet et à quoi ressemblaient la matrice des livrables et tous les livrables à ce moment-là.

Mike peut ouvrir la section « Version » de ce projet, où sont conservées toutes les versions et les bases de référence du projet. Il peut revenir à la révision D et l’ouvrir. Lorsque nous ouvrons la révision D du projet, nous voyons clairement que le dépôt du brevet faisait partie de la phase de conception, alors qu’il fait désormais partie du prototype d’ingénierie.

Dans cette base de référence, Minerva PLM conserve non seulement l’historique de ce qui se trouvait dans chaque phase, mais nous gardons également une trace de la version de chaque livrable qui est réellement valide à tout moment. Et si vous ouvrez un fichier, un livrable ou une partie d’une version précédente, vous serez toujours redirigé vers la version spécifique du livrable qui était valide à ce moment-là, ce qui vous offre une piste d’audit très solide et une base de référence fiable pour vos projets.

La capture du dossier historique de conception et de la fiche de base du dispositif ne sont que deux exemples de structures de documentation exigées par les organismes de réglementation. Elles sont associées à un dispositif ou à un produit, et nous devons être en mesure de saisir les modifications qui y sont apportées afin d’éviter un travail manuel fastidieux. Une solution devra bien sûr prendre en charge cette tâche et assurer le suivi de chaque modification et de chaque référence.

Mais plusieurs de nos clients constatent qu’il existe d’autres structures de documentation, par exemple un dossier technique qui doit également être géré comme le DHF et le DMR, selon le territoire sur lequel vous opérez. Dans une société, l’équipe travaille à la conception d’un nouveau ventilateur respiratoire. Comme vous pouvez l’imaginer, le développement d’un tel équipement est un projet très complexe et il est essentiel de disposer d’une traçabilité complète de ce qui a été fait par qui et de ce qui a été modifié, non seulement pour mettre plus rapidement les ventilateurs sur le marché, mais aussi pour obtenir les autorisations requises des organismes de réglementation. Dans cette entreprise, les changements de projet ne sont plus un cauchemar. Voyons comment Minerva PLM les prend en charge. Aujourd’hui, je me lance dans mon projet et je commence à travailler sur le dépôt de brevet pour mon projet de ventilateur.

Je me rends dans le projet, je l’ouvre pour trouver la matrice des livrables et identifier où se trouve mon dépôt de brevet. Lorsque j’ouvre le projet, je constate que bon nombre de mes livrables n’ont pas encore été créés, et je peux également voir à quel produit ils correspondent, quel produit est en cours de création dans le cadre de ce projet de développement.

Et bien sûr, ces livrables doivent également faire partie du DHF et de tous les DMR pour ce produit. Donc, si j’ouvre le produit, je vois que j’ai deux onglets. Je peux ouvrir l’onglet « Fichier d’historique de conception », et là, je vois le DHF généré automatiquement pour ce ventilateur. Comme je peux le voir, je peux voir le statut du projet pour chacun d’entre eux.

Et si je regarde le dépôt de brevet, je vois qu’il est en attente. Il devrait être terminé d’ici le 4 septembre, mais il n’a pas encore été créé. Si je retourne maintenant à mon projet, je peux rechercher mon dépôt de brevet. Le système effectuera alors une recherche dans ma grille et je verrai que le concept d’interface se trouve à l’endroit où je l’ai enregistré.

Je vois que j’ai la ligne pour le livrable, mais qu’elle n’a pas encore été créée. En cliquant sur « Instantiate », le système va chercher le modèle pour le dépôt de brevet et créer automatiquement le document pour moi. Comme vous pouvez le voir maintenant, ce document a été créé automatiquement à partir du modèle pour le dépôt de brevet. Si je regarde le DHF dans le contexte du projet, je peux maintenant voir que le dépôt de brevet a été créé.

Le M3 et le DHF ont le document qui s’y rapporte. Si je retourne à la pièce, je peux le voir dans l’onglet DHF de la pièce. J’ai également créé le dépôt de brevet. Ainsi, le DHF est automatiquement mis à jour en fonction de ce que je fais dans mon projet. Cela me permet de m’assurer beaucoup plus facilement que tout est aligné et correct.