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

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.

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

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

 

7 conseils pour collaborer avec un programmeur SAS

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.