Posts Tagged ‘essais cliniques’

h1

Pharmaceutique : Good Clinical Practice

janvier 22, 2012

Chaque secteur d’activité a ses documents de référence. Dans le secteur pharmaceutique l’un d’entre eux est « International Conference  on Harmonization – Good Clinical Practice – ICH GCP ». Ce document est une excellente base pour comprendre le déroulement des essais cliniques et se familiariser avec un vocabulaire qui lui est propore comme « monitor », « investigator », « sponsor », « protocol », « serious adverse event », « double-blind/single-blind/open-label ». Une culture générale qui peut s’avérer utile aux programmeurs SAS.

Vous trouverez sur le net plusieurs ressources dont : http://ichgcp.net

h1

7 conseils pour collaborer avec un programmeur SAS

novembre 13, 2008

Vous devez travaillez avec programmeur SAS et souhaitez connaître quelques petits trucs qui faciliteront cette collaboration. Cet article est fait pour vous. Les exemples traiteront principalement de la pharmaceutique mais peuvent être aisément généralisés.

1. Répondez rapidement à leurs questions

Maintenez le flux d’information : Lorsqu’un programmeur pose une question, il a souvent besoin de la réponse immédiatement pour pouvoir continuer à avancer dans son travail. Vous avez à peu prêt une marge d’une demi-journée pour réponse. Si vous répondez dans les 5 minutes c’est encore mieux. Faute de réponse, il sera obligé d’arrêter de travailler sur le projet. Le temps de réimmersion dans un projet est long et pesant pour un programmeur. En effet, le programmeur oublie très rapidement ce qu’il a fait et pourquoi même si il documente ces programmes. Imposez lui ces contraintes et il sera encore moins enclin à reprendre le processus et c’est vous qui risquez de voir vos dates butoires passer aux oubliettes.

2. Coupez vos réponses

Ecrire un mail par problématique vous donnera plus de chance d’en voir une partie de traitées rapidement. Si vous envoyez un bloc, cela effrayera le programmeur. Il aura tendance à traiter les réponses simples et rapide en premier. Faites partie de ses priorités.

3. Soyer précis dans vos demandes

Apportez votre expertise sur les données : Bien sûr, vous ne connaissez pas tous les surprises dans les données qui seront visibles une fois seulement le travail du programmeur en partie accomplie. Néanmoins, vous êtes le spécialiste sur ces données. Vous savez quand des valeurs sont aberrantes, comment les variables doivent être définies.

4. Garder un document de référence commun

Encouragez le programmeur à rédiger un document résumant les choix qu’il fait lors de l’écriture de ses programmes. Dans le cas de la rédaction d’une macro, il est obligé d’écrire divers documents :

  • un document technique (specification)
  • un manuel utilisateur (user manual)
  • un récapitulatif des tests effectués (test plan)
  • un diagramme décrivant le processus du programme (flowchart).

A tord, il rédige souvent ce type de document après avoir fini la partie programmation. Incitez-le à commencer la rédaction dès le début et à poursuivre les mises à jour au fur-et-à mesure.

Reste que dans le cas de la programmation lié au transfert de données ou à la création de tables statistiques aucun document n’est souvent demandé. Les Statistical Analysis Plan (SAP) pour les tables statistiques ne sont pas encore généralisées. Il est très pratique d’avoir un document sur lequel le programmeur listera les choix fais, les points en suspend demandant clarification de votre part, etc.

5. Informez-le des délais à respecter et vos attentes

Informez-lui de l’agenda de l’étude, des décisions majeures : Tenez compte du fait que le programmeur n’est impliqué que sporadiquement dans une étude clinique. Il sera consulté seulement à une certaine période du processus. Il n’aura quasiment pas d’information sur l’étude à part le protocole. Il n’aura pas été invité aux réunions pour présenter les enjeux de l’études, pour écouter les discussions sur les spécificités des patients et n’est en général pas tenu au courant des résultats de l’études à part un : les résultats sont positifs ou pas. De plus, il remplacera parfois un autre programmeur en cours de projet ou sera remplacé par un autre.

6. Expliquez les enjeux du projet

Faites-lui partager vos motivations et les enjeux que représentent l’étude sur laquelle vous l’impliquez. Le programmeur doit travailler sur plusieurs études et projets à la fois. Il n’a pas donc les moyens de se motiver pour chaque particularité d’une étude.

7. Ne modifiez pas le travail effectué par le programmeur

Si vous ne vous sentez pas à l’aise avec la programmation sous SAS, ne commencez pas à ajouter des programmes qui affecteront les travaux de votre programmeur. Respectez le rôle de chacun.

h1

Le monde du programmeur SAS en pharma

février 21, 2008

pharmacie.jpg 

L’environnement professionnel du programmeur SAS dans le secteur pharmaceutique et plus précisément dans la partie essais cliniques peut ressembler à une boîte noire. Hors SAS est un standard dans ce secteur et les besoins en programmeurs y sont récurrents. Il est donc fort enrichissant d’avoir une connaissance de ce milieu.

Pour une immersion dans l’univers des essais cliniques, je vous propose l’article sur le sujet a été écrit par Sy Truong, Meta-Xceed : Clinical Trials Terminology for SAS Programmers. Voici une traduction du résumé et de l’introduction pour vous donner un avant goût de cet article.

« Le processus de développement des médicaments/drogues est un processus clinique qui a son propre langage. La fonction des programmeurs SAS n’a pas besoin d’être MD ou expert de la réglementation mais une connaissance des terminologies professionnelles est importante pour être efficace. Cet article couvrira le processus de développement d’une drogue de la découverte à la phase IV. Il expliquera le large éventail d’acronymes comme IND, NDA, GCP et MedDRA. Il décrira également certaines terminologies utilisées dans le processus des essais cliniques lorsqu’une drogue est développée et soumise au FDA. Cela donnera aux programmeurs SAS une perspective plus large et un contexte à leur travail durant l’analyse et le rapport de données d’essais cliniques. »

« Cet article va vous raconter une histoire fictive concernant un diplômé de l’enseignement supérieur nommé James qui commence un nouvel emploi dans une entreprise pharmaceutique. Chaque nouveau terme que James rencontre est présenté en gras et en italique pour le faire ressortir. En entrant dans un nouvel cercle professionnel, il rencontre beaucoup de personnes et apprend de nouveaux processus remplis de vocabulaires et d’acronymes non familiers. Au fur et à mesure que James s’immerge dans son nouveau job en tant que programmeur SAS, il apprend le sens des terminologies et devient plus productif au travail. »

Pour faire face à un vocabulaire technique en anglais, je vous conseille vivement le dictionnaire français-anglais du site québécois www.granddictionnaire.com.