L i v r e B l a n c. Graduer les mesures qualités lors de la mise en œuvre d'un système MES configurable. Livre Blanc

Transcription

1 Graduer les mesures qualités lors de la mise en œuvre d'un système MES configurable. Rolf Blumenthal, Werum Software & Systems AG Livre Blanc L i v r e B l a n c

2 Sommaire Le temps est quasiment révolu, où les entreprises pharmaceutiques généraient d importants volumes de papier pour imprimer les dossiers de fabrication, conséquence directe de la production de médicaments. Aujourd'hui la documentation pharmaceutique est gérée électroniquement. Ceci contribue non seulement à sauver des arbres mais réduit aussi considérablement les efforts indispensables de révision et de vérification des documents. Les systèmes informatiques se chargent des contrôles de routine des données saisies, permettant ainsi au personnel AQ de se concentrer sur les exceptions et d'évaluer leurs conséquences éventuelles sur la qualité des produits pharmaceutiques (review by exception/contrôle par exception). L'usage de systèmes informatisés a un impact profond sur les procédures établies de fabrication. De tels systèmes doivent donc faire l'objet d'une méthode de validation basée sur la réglementation nationale et internationale régissant le secteur pharmaceutique. L'objectif de la validation est de s'assurer que ces systèmes répondent aux plus hauts standards de qualité en termes de procédés de développement et processus opérationnels. Le nouveau guide «Good Automated Manufacturing Practice» (GAMP ) est un document explicatif qui fournit des recommandations pratiques et utiles sur les méthodes et procédés adaptés au développement de logiciels. Il traite de l'ensemble du cycle de vie d'un logiciel depuis le processus de planification, puis les phases d'implémentation et d'exploitation jusqu'au retrait éventuel du système et illustre ses recommandations par des exemples pratiques et des modèles issus du terrain. Dans la dernière version GAMP 5, il est recommandé aux entreprises lors du déploiement de systèmes configurables, de graduer leurs efforts de validation basée sur la pratique d'analyse de risques et d'intégrer les documents fournisseurs à plus grande échelle dans le processus de validation. 2/17

3 Quelles sont les nouveautés de GAMP 5? Le nouveau guide GAMP 5 a été publié en mars Au-delà des nombreuses améliorations de détail qu'il apporte, le changement fondamental du mode de penser paraît évident quand on le compare aux versions précédentes. La dernière version du guide GAMP porte l'accent sur la graduabilité des procédures et des méthodes appliquées, aboutissant à une meilleure efficacité des mesures qualité sans perdre de vue l'objectif premier : la sécurité des patients. Cet article se concentre sur les recommandations faites en termes de graduabilité des activités liées au cycle de vie des systèmes informatisés et tente dans ce contexte d'élaborer les normes de service que les entreprises pharmaceutiques, de nos jours, sont en droit d'attendre de la part de leurs fournisseurs de systèmes informatiques. Rapprochement accru des entreprises pharmaceutiques et des fournisseurs de systèmes À l'origine, le guide GAMP visait à aider les fournisseurs de systèmes informatiques à comprendre les exigences réglementaires spécifiques de l'industrie pharmaceutique et en conséquence à fournir des systèmes informatiques de haute qualité. Les auteurs de la dernière version du guide GAMP 5 révèlent toutefois l'apparition d'un changement de perception dans le secteur pharmaceutique. Ils ont dû prendre en considération le fait que la plupart des fournisseurs de systèmes informatiques avaient déjà amélioré de façon significative, tant la qualité de leurs systèmes, que les méthodes et procédures internes de développement concernées. Ceci débouche sur la recommandation d'adopter le savoir-faire et les activités des fournisseurs et de les intégrer dans une plus large mesure dans les procédures internes des entreprises pharmaceutiques (voir fig. 1). 3/17

4 Fig. 1 : les mondes des entreprises pharmaceutiques et des fournisseurs de systèmes se rapprochent En effet, pourquoi ne pas profiter des travaux déjà réalisés par les fournisseurs de systèmes lors de l'implantation de nouveaux systèmes informatisés? Pourquoi un test fonctionnel effectué par le fournisseur et selon les recommandations GAMP ne suffirait-il pas à remplacer un test réalisé sur le site du client, ou à servir au moins de base au contrôle du suivi interne? Les clients devraient au fond se servir de la documentation, des tests et de l'équipement de test procurés par les fournisseurs et déterminer le moyen d'intégrer directement ces ressources dans leurs propres processus de gestion des cycles de vie des logiciels. Mais il existe également de nombreux avantages pour le fournisseur : les entreprises pharmaceutiques peuvent, par exemple, s'impliquer dans les tests fonctionnels des fournisseurs, et ceci bien avant que le système ne soit livré. Si une entreprise pharmaceutique remarque que le système ne répond pas à ses exigences spécifiées, les procédures de livraison coûteuses peuvent être différées jusqu'à ce que les deux parties soient certains que toutes les exigences de l'utilisateur final soient pleinement satisfaites. 4/17

5 Dans cette optique, les exigences suivantes doivent être respectées par les deux parties le client et le fournisseur : Un système établi de gestion de la qualité L'usage d'un système de gestion de la qualité qui soit fonctionnel, bien conçu et qui supporte les activités courantes qui aide au lieu de freiner les processus est un pré-requis essentiel pour tirer pleinement profit du logiciel et des services procurés par le fournisseur. Le client pharmaceutique doit auditer ce système de gestion de la qualité sur le site de son fournisseur de systèmes afin d'établir un point de référence qui identifiera par la suite la qualité des produits du fournisseur. Une compréhension des processus Un fournisseur de systèmes doit disposer d'une bonne compréhension des processus de ses clients pour être en mesure de contribuer de façon significative et active à une collaboration fournisseur-client fructueuse. Pour développer un système qui réponde réellement aux besoins du client, le fournisseur de systèmes doit disposer d'une connaissance claire du fonctionnement des processus de fabrication du client. Les spécifications du logiciel requièrent en particulier une connaissance précise des processus existant sur les sites du client, car cette information représente un élément majeur pour la définition des fonctions qui supporteront les opérations effectuées par l'utilisateur final. Une description claire, compréhensible et sans ambigüité du besoin des utilisateurs (URS : User Requirements Specification) est un point essentiel et est considérée comme une condition préalable fondamentale citée dans toutes les versions du guide GAMP. Une description précise de tous les processus qui seront supportés par le système informatisé L'utilisation de graphiques décrivant la définition des processus dans le système peut être comparée à l'architecte s'appuyant sur ses plans pour donner à son client une idée de l'apparence finale du bâtiment. Il existe de nombreuses normes et outils établis pour générer des éléments graphiques pouvant être appliqués au développement d'un langage qui sera compris par les deux parties. 5/17

6 La compréhension du système Un client pharmaceutique doit transmettre des informations à son fournisseur, à différent stades du cycle de vie d'un produit, même dans le cas de l'achat d'un système complet. L'entreprise pharmaceutique est par exemple impliquée dans le premier audit, dans la procédure de définition de la spécification fonctionnelle, dans la conduite d'analyse et d'évaluation de risques liés aux processus et aux fonctions, ainsi que dans la réalisation de tests. Mieux le client comprendra comment de tels systèmes sont développés, plus efficaces seront ces travaux. Le guide GAMP utilise dans ce contexte le terme subject matter experts (SME : experts en la matière) et suggère de leur attribuer un plus grand rôle. En suivant ces recommandations de collaboration client-fournisseur, une entreprise pharmaceutique peut ainsi s'épargner un redoublement d'efforts et accéder à une meilleure efficacité en faisant bon usage des activités AQ de son fournisseur. A cet égard, la sécurité du patient, la qualité des produits et l'intégrité des données sont quelques-uns des critères que tout fabricant de médicaments doit considérer comme étant de première nécessité. 6/17

7 La catégorie d'un système détermine l'ampleur des activités liées au cycle de vie Selon le guide GAMP 5, la classification du système dépend des activités liées au cycle de vie ainsi que des résultats d'évaluation des risques et des fournisseurs. La catégorie d'un système a donc un impact sur l'approche des cycles de vie. Ceci est plus clair quand on observe les diverses variations de l'approche des différentes catégories. Dans le cas de systèmes non-configurés de catégorie 3 (voir fig. 2), l'approche nécessite moins d'activités que pour les systèmes de catégorie 4 ou 5, qui eux sont modifiables par changement de configuration ou par personnalisation (customizing). Fig. 2 : approche pour les systèmes de catégorie 3 : produits non configurés Dans un système configurable (catégorie 4), la configuration doit être aussi définie, décrite et testée (voir fig. 3). Dans un système personnalisé (catégorie 5), il faut également prendre en considération les spécifications et le développement du logiciel, ainsi que les tests qui y sont liés (voir fig. 4). 7/17

8 Fig. 3 : approche pour les systèmes de catégorie 4 : produits configurés Fig. 4 : approche pour les systèmes de catégorie 5 ; applications personnalisées 8/17

9 La sécurité des patients le point de référence dans l'évaluation des risques Le guide GAMP 5 suit pour les systèmes informatisés une approche fondée sur les risques, qui a été développée par la FDA il y a quelques années lors du lancement de son initiative Pharmaceutical cgmps for the 21 st Century : A Risk-based Approach (les Bonnes Pratiques de Fabrication courantes pharmaceutiques au 21ème siècle : une approche fondée sur les risques). Cette approche exige une évaluation des risques à différents niveaux de la planification. Il est en effet recommandé de commencer un projet par une évaluation initiale des risques liés au système, qui devrait être suivie par une évaluation plus détaillée des risques liés aux fonctions utilisateur lors de la phase des spécifications. Ceci signifie que le guide GAMP 5 recommande de fonder ses décisions sur l'analyse de risques et d'utiliser ces résultats comme point de départ des mesures d'atténuation. La valorisation des risques doit être réalisée de façon scientifique. Dans ce but, les entreprises doivent user de méthodes prenant en considération des facteurs tels que la probabilité d'occurrence, l'étendue des conséquences potentielles, les raisons d'une erreur et la difficulté à atténuer les risques identifiés. Les activités liées au cycle de vie et la documentation inhérente peuvent ensuite être graduées en fonction des risques impliqués, de la complexité, du degré et du type de personnalisation requis. Un aspect entièrement nouveau de l'analyse de risques, tel que décrit dans le guide GAMP 5, est la pondération des risques en fonction de la sécurité des patients, de la qualité des produits et de l'intégrité des données. Il existe effectivement des points de référence des risques externes au système analysé. Ceci signifie que les risques ayant été classifiés comme sérieux à l'intérieur du système peuvent être considérés comme négligeables d'un point de vue de la sécurité du patient. En contrepartie, un mauvais calcul des coûts d'un produit n'affectera pas la sécurité des patients et ne sera donc pas classé comme un facteur à haut risque, bien qu'une telle erreur constitue certainement un haut risque du point de vue commercial. Si l'on suppose que le niveau de risque est basé sur une distribution gaussienne, l'introduction du critère «sécurité des patients» permet de réduire de façon significative les mesures nécessaires d'atténuation. Ceci ne libère toutefois pas les fournisseurs de leurs obligations contractuelles liées aux tests de leurs systèmes. 9/17

10 Le MES : une étude de cas pour un système logiciel configurable Dans l'industrie pharmaceutique, les MES (Manufacturing Execution System) sont utilisés pour exécuter les tâches liées à différents domaines, tels que la création de dossiers de fabrication pharmaceutiques, le contrôle et le suivi des matières entrantes ou des équipements utilisés en production. Ils supportent et facilitent les contrôles de routine des données collectées et saisies sur le site. Ceci permet au personnel AQ de se concentrer exclusivement sur les exceptions et d'évaluer les effets qu'elles pourraient avoir sur la qualité du produit pharmaceutique (review by exception). Les tâches étant ainsi définies, il paraît assez évident que les systèmes MES comprennent des fonctions pouvant présenter des risques particuliers au regard de la sécurité des patients et de la qualité du produit. Les systèmes MES doivent également être conformes à la réglementation nationale et internationale qui régule le secteur pharmaceutique, car les exigences réglementaires appliquées aux procédures papier traditionnelles, telles que les exigences FDA de Bonnes Pratiques de Fabrication courantes (BPF / cgmp), sont aussi applicables aux procédures électroniques. Ceci a pour conséquence de générer en aval d'un système MES un haut niveau d'exigence en matière de qualité des procédés de développement et de vérification. Les sections suivantes décrivent des méthodes pouvant être appliquées pour satisfaire à ces contraintes dans un environnement MES, en conformité avec les recommandations citées dans le guide GAMP 5. 10/17

11 Approche du cycle de vie par la graduation fondée sur les risques Aujourd'hui, la mise en œuvre de systèmes MES n'offre un bon rapport coût-efficacité que si les MES sont basés produit et non faits sur mesure. Ils peuvent être adaptés pour satisfaire aux exigences spécifiques des clients en configurant le produit et - mais seulement dans une certaine limite - en personnalisant le logiciel. Si l'approche suggérée par le guide GAMP 5 est adoptée, les activités liées au cycle de vie doivent être en conformité avec les recommandations concernant les systèmes de catégorie 4, c'est-à-dire les «produits configurés». Une variante peut se révéler utile pour pouvoir soutenir le développement permanent d'un produit en utilisant, autant que possible, toujours les mêmes méthodes. Dans cette variante, les exigences spécifiées pourront être remplies par les changements de configuration et/ou les modifications du logiciel (voir fig. 5). Fig. 5 : analyse de risques au cours des différentes phases du cycle de vie du logiciel Les systèmes MES fournissant un nombre croissant de fonctions complexes, la graduation fondée sur les risques des activités liées au cycle de vie peut apporter une contribution considérable aux gains de productivité. La première évaluation des risques devrait porter sur les processus gérés par le MES, plutôt que sur les fonctions à implémenter. Une expertise et une connaissance particulière de l'industrie pharmaceutique sont cependant indispensables à l'évaluation des risques liés aux processus. Seul un spécialiste pharmaceutique de la compagnie, soit une «personne qualifiée», est capable de prendre une décision finale touchant à la pertinence BPF d'une étape de processus donnée. La révision et l'approbation de documents de production (21 11/17

12 CFR Part Production Record Review) représentent un exemple d'étape de production. Au cours de cette première évaluation, le focus est porté vers les procédures critiques BPF. Le potentiel de graduabilité qui y est associé est basé sur les critères externes concernant la sécurité des patients et la qualité du produit. L'analyse des risques liés aux processus ayant lieu très tôt dans la phase de planification, la réaction face à un grand risque BPF peut même déboucher sur le changement de certaines exigences utilisateurs préalablement définies. Dans la phase suivante du détail de l'évaluation des risques, on se concentrera sur les risques liés aux fonctions utilisées du MES, risques qui devront être considérés en fonction de ceux identifiés dans la première phase d'évaluation. Cette évaluation étant purement technique, le fournisseur de logiciels peut l'effectuer de lui-même, mais une vérification doit toujours être effectuée en aval par le fabricant pharmaceutique. Dans ce processus d'évaluation, la probabilité d'occurrence, la probabilité de détection et les conséquences anticipées d'une erreur sont d'abord examinées et les risques identifiés sur la base des résultats obtenus sont alors classifiés comme étant faibles, moyens ou élevés. En plus de différencier les «erreurs utilisateurs» des «erreurs système», différents moyens peuvent être mis en œuvre pour atténuer le risque, tel que la définition du type et de l'étendue d'un test ou l'introduction de nouvelles procédures opérationnelles pour les opérateurs pharmaceutiques. Les procédures de test décrites dans l'analyse des risques doivent être formulées de façon à pouvoir être utilisées «telles quelles» dans les spécifications de test. Ceci signifie que l'analyse des risques fonctionnels a un impact direct sur le test fonctionnel et détermine le niveau et l'étendue des activités de test qui sont nécessaires. Une troisième analyse de risques a lieu au cours de la phase de développement afin d'évaluer l'impact qu'un changement aurait sur la stabilité du système existant. Les changements de grande importance (ayant des effets secondaires considérables) réclament des mesures plus étendues et complexes qu'un ajustement mineur se limitant à une séquence de code. Il est toutefois possible de réduire les efforts en utilisant un logiciel-produit pré-testé dont les activités de minimisation du risque ont déjà été réalisées pour toutes les fonctions qui demeureront inchangées dans le projet. Donc, si la fonction de connexion par exemple a déjà été testée en tant que partie intégrante du produit, le test effectué peut être référencé dans le processus d'évaluation des risques du projet. Les tests client supplémentaires ne sont alors plus nécessaires, ou du moins ils sont réduits de façon significative. 12/17

13 Connaissance des processus en tant que pré-requis pour les logiciels configurables Comme leurs noms le suggèrent déjà, les Manufacturing Execution Systems sont conçus pour fournir un soutien optimal aux processus impliqués dans la fabrication de produits. Le mot «fabrication» inclut la production chimique ou pharmaceutique de substances actives, de même que la production et le conditionnement des médicaments sous diverses formes de dosage. Il paraît évident que les personnes impliquées dans le développement de fonctions logicielles dédiées au support de tels processus disposent d'une connaissance très développée des secteurs industriels concernés. Plus l'accent est mis sur un produit informatique réutilisable, c'est-à-dire un logiciel qui est utilisé de façon répétée sous différentes configurations, meilleur doit être cette compréhension des processus. Que les concepteurs du logiciel soient simplement familiers avec un processus ne suffirait pas dans un tel cas. Ils devront aussi être très versés en variations de processus, c'est-à-dire savoir «quels boutons manipuler» pour livrer la configuration recherchée. Il est recommandé d'utiliser un langage clair et sans ambigüité pour décrire les processus, ce qui est la meilleure méthode pour garantir une bonne communication entre les experts en la matière (SME) et les concepteurs de logiciels. Le besoin d'une communication précise et efficace à ce niveau est reflété par l'existence sur le marché d'une variété de langages de description des processus et d'outils assortis. Le langage de modélisation des processus métiers BPML (Business Process Modeling Language) est un langage très répandu, utilisant des éléments graphiques pour décrire les processus (voir fig. 6). 13/17

14 Fig. 6 : exemple de description de processus avec langage BPML Il est important de noter que ce type de description nécessite un niveau adéquat de détails pour être certain que l'utilisateur et le développeur puissent communiquer ensemble de manière simple mais claire et arriver à une compréhension commune des processus à supporter en identifiant les fonctions nécessaires, mais sans se perdre dans les détails. Ce type de description de processus peut servir à décrire le fonctionnement du système standard pour les logiciels-produits configurables. Ce modèle de description représente pour le fournisseur de logiciels un excellent outil de communication pour identifier ce que le client doit considérer au niveau processus comme étant soit un workflow standard, soit un élément de configuration ou un élément de développement. Une fois la description des procédés bien débattue, les fonctions requises peuvent alors être spécifiées, l'analyse fonctionnelle des risques peut être réalisée et les phases individuelles de test peuvent commencer. Cette procédure facilite le suivi des configurations et des changements, car elle permet de les relier immédiatement à la description du processus. 14/17

15 Le MES pharmaceutique plus qu'un simple logiciel Un produit standard configurable est manifestement plus qu'une simple description des processus il comprend aussi une spécification fonctionnelle appropriée, une analyse des risques et les spécifications de test qui en dérivent. Une analyse fit/gap peut être conduite au tout début du projet pour comparer les processus standards décrits avec ceux existants ou souhaités. Le client pharmaceutique peut alors décider d'implémenter le processus standard (Best Practice) ou d'y apporter les modifications nécessaires (Best Fit), le risque inhérent à de tels changements sera alors déterminé en se basant sur la connaissance de ses propres processus. Les résultats de l'analyse fit/gap aide le client à prendre les décisions concernant la configuration et l'adaptation du logiciel et des documents qui en découlent. Le client pharmaceutique utilise sa profonde connaissance du processus pour décider du degré approprié de graduation et ceci très tôt dans le cycle de vie. L'usine virtuelle développement de produit basé sur des processus réalistes Pour obtenir les meilleurs résultats, le fournisseur devrait fonder son modèle complet de développement logiciel sur la description du processus en partant du produit standard configurable. Avec un logiciel configuré et paramétré pour s'adapter aux processus standards, il est possible d'effectuer des tests aussi réalistes que possible dans ce qui est convenu d'appeler une «usine virtuelle». En conséquence, les résultats de tests obtenus avec un logiciel standard peuvent aussi être utilisés en grande partie pour les tests fonctionnels de l'application effectués ultérieurement chez le client. 15/17

16 GAMP 5 encourage la graduation des activités liées au cycle de vie Le but de ce livre blanc était d'illustrer la possibilité de graduation des activités liées au cycle de vie d'un système informatisé complexe dédié au soutien des processus critiques selon les BPF. Il a été présumé que le produit standard était bien documenté grâce à une définition de processus précise et compréhensible de son usage et qu'il existait bien une analyse des risques, une spécification de tests et des tests réalisés s'appuyant tous sur cette description de processus. Quand un tel produit doit être implémenté, la première étape est représentée par une analyse fit/gap, suivie par une configuration ou une personnalisation du logiciel et de tous les documents associés. La plupart des travaux préliminaires ayant été réalisés lors de phases précédentes, les activités du projet peuvent alors se limiter au traitement des changements. Le tout s'effectue sur la base des recommandations de catégorisation des systèmes GAMP 5, sur les approches fondées sur les risques et sur l'intégration des activités du fournisseur avec celles du client. GAMP 5 encourage l'utilisation de l'analyse économique des projets de systèmes informatisés, sans négliger les questions de conformité. Le but est de faire de l'installation d'un nouveau logiciel un projet rentable, tout en minimisant les risques concernant la qualité produit. 16/17

17 Ce livre blanc est proposé à des fins informatives, sans contenir ni constituer de conseil légal. Werum se décharge expressément de toute responsabilité qui pourrait résulter des déclarations faites dans ce livre blanc ou toute autre action prise par des tiers suite à la lecture que ces déclarations. Werum Software & Systems AG Wulf-Werum-Strasse Lunebourg, Allemagne Tél.: +49 (0) Fax: +49 (0) info@werum.com 17/17