Posts Tagged ‘pharmaceutique’

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

Combien de nouveaux cas par an ? Une mesure d’incidence

juillet 25, 2010

L’incidence est une mesure statistique utilisée couramment dans les études cliniques, en cancérologie notamment. Vous trouverez sur Wikipédia une explication en termes simples de ce concept. Voici quelques extraits: définition et exemple de base.

1. Le principe de base

Wikipedia, définition : « En général, l’incidence (ou le taux d’incidence) est le nombre de nouveaux cas d’une pathologie observés pendant une période et pour une population déterminée. »

Taux d’incidence=nombre de nouveaux cas/durée totale du suivi

Wikipedia, exemple : « Par exemple, si 100 personnes à risque ont été étudiées pendant 2 ans, la durée totale de suivi est de 200 personnes-années.Dans ce même exemple, s’il a eu 5 nouveaux cas de la maladie à l’étude, le taux d’incidence sera de 5 cas par 200 personnes-années, ou plus simplement de 2,5 cas par 100 personnes-années (ou encore 0,025 cas par personne-année). »

Taux d’incidence=5/200

2. Le vrai taux d’incidence

Wikipedia, définition : « En général, on s’intéresse à la première occurrence d’une maladie donnée chez une personne (au premier cancer et pas à ses récidives chez un même patient par exemple). »

Wikipedia, l’exemple: « Dans l’exemple précédent, les cinq cas diagnostiqués pendant l’étude ne sont plus à risque à partir du moment où ils sont diagnostiqués. S’ils ont contracté la maladie après six mois d’observation, ils n’ont été à risque que pendant six mois. La durée totale de suivi pour cette étude est donc

  • de 190 personnes-années pour les personnes qui n’ont pas la maladie (95 personnes fois 2 ans) et
  • de 2,5 personnes-années pour les cas (6 mois fois 5 cas).

Le vrai taux d’incidence est donc de 5 cas sur 192,5 personnes-années (ou 2,6 cas par 100 personnes-années). »

Taux d’incidence=5/192.5

L’éventail d’application de cette mesure s’étant au delà de la pharmaceutique. Nombre de personnes ayant retrouvé un emploi, nombre de clients ayant effectué un nouvel achat dans l’année après être passé au statuts de client perdu, etc.

Complétez cet article

N’hésitez pas à ajouter des précisions tant sur le calcul avec SAS, que sur la gestion des valeurs manquantes, identifier une différence significative entre deux taux d’incidence ou la représentation graphique de ce type de données.

h1

Sponsor et CRO : Réunion de début d’étude détaillée

novembre 2, 2009

Dans le monde pharmaceutiques deux termes reviennent fréquemment : sponsor qui développent les médicaments et CRO (clinical research organisation) vers lesquelles sont externalisées une partie des études. A ces termes est souvent associé la question : comment améliorer la collaboration entre les deux. Ce fût en tous les cas le sujet de plusieurs interventions lors de la conférence annuelle PHUSE (Pharma SAS Users) de Bâle (Suisse) en octobre.

Voici quelques notes prises lors de PHUSE sur la réunion de début d’étude entre sponsor et CRO. Cette réunion est l’occasion d’établir un premier contact entre les intervenants de l’étude. Mais elle peut aussi permette de clarifier certains points. Un agenda détaillé pourra optimiser votre temps :

  • Donner une vue d’ensemble sur le projet et des informations propres à l’étude
  • Citer les problèmes potentiels déjà envisagés
  • Fournir des détails sur le processus suivi par le sponsor pour conduire une étude
  • Expliquer les objectifs que doivent servir les documents à fournir au sponsor
  • Clarifier les dates à respecter des deux côtés
  • Préciser les ressources humaines et technologiques nécessaires des deux côtés
  • Débuter un document traçant les décisions prises

 

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.