Chapitre 19 Étapes de l’étude

Chefs de chapitre : Sara Dempster & Martijn Schuemie

Ici, nous visons à fournir un guide général étape par étape pour la conception et la mise en œuvre d’une étude observationnelle avec les outils OHDSI. Nous allons diviser chaque étape du processus d’étude, puis décrire les étapes de manière générique et dans certains cas, discuter des aspects spécifiques des principaux types d’études (1) caractérisation, (2) estimation au niveau de la population (PLE) et (3) prédiction au niveau du patient (PLP) décrits dans les chapitres précédents du Livre d’OHDSI. Pour ce faire, nous synthétiserons de nombreux éléments discutés dans les chapitres précédents d’une manière accessible pour les débutants. En même temps, ce chapitre peut se suffire à lui-même pour un lecteur qui veut des explications pratiques de haut niveau avec des options pour approfondir les matériaux dans d’autres chapitres si nécessaire. Enfin, nous illustrerons tout au long avec quelques exemples clés.

De plus, nous résumerons les lignes directrices et les meilleures pratiques pour les études observationnelles recommandées par la communauté OHDSI. Certains principes que nous discuterons sont génériques et partagés avec les recommandations de meilleures pratiques trouvées dans de nombreuses autres directives pour la recherche observationnelle, tandis que d’autres processus recommandés sont plus spécifiques au cadre OHDSI. Nous soulignerons donc où les approches spécifiques à OHDSI sont rendues possibles par la suite d’outils OHDSI.

Tout au long du chapitre, nous supposons qu’une infrastructure d’outils OHDSI, R et SQL est disponible pour le lecteur et nous ne discutons donc d’aucun aspect de la configuration de cette infrastructure dans ce chapitre (voir les Chapitres 8 et 9 pour des conseils). Nous supposons également que notre lecteur est intéressé à effectuer une étude principalement sur les données de son propre site en utilisant une base de données dans l’OMOP CDM (pour OMOP ETL, voir le Chapitre 6). Cependant, nous soulignons qu’une fois qu’un paquet d’étude est préparé comme discuté ci-dessous, il peut en principe être distribué et exécuté sur d’autres sites. Des considérations supplémentaires spécifiques à la réalisation d’études en réseau OHDSI, y compris les détails organisationnels et techniques, sont discutées en détail dans le Chapitre 20. ## Lignes Directrices Générales de Bonnes Pratiques

19.0.1 Définition de l’Étude Observatoire

Une étude observationnelle est une étude où, par définition, les patients sont simplement observés et aucune tentative n’est faite pour intervenir dans le traitement de patients spécifiques. Parfois, des données observationnelles sont collectées à des fins spécifiques comme dans une étude de registre, mais dans de nombreux cas, ces données sont collectées pour une autre raison que la question d’étude en cours. Des exemples courants de ce dernier type de données sont les dossiers de santé électroniques (DSE) ou les données de réclamations administratives. Les études observationnelles sont souvent qualifiées d’utilisation secondaire des données. Un principe directeur fondamental pour réaliser toute étude observationnelle est de décrire explicitement sa question de recherche et de spécifier entièrement l’approche avant d’exécuter une étude. À cet égard, une étude observationnelle ne devrait pas être différente d’un essai clinique, sauf que dans un essai clinique, les patients sont recrutés et suivis dans le temps dans le but principal de répondre à une question spécifique, généralement sur l’efficacité et/ou la sécurité d’une intervention thérapeutique. Il existe de nombreuses façons dont les méthodes d’analyse utilisées dans les études observationnelles diffèrent de celles utilisées dans les essais cliniques. Notamment, l’absence de randomisation dans les études observationnelles PLE nécessite des approches pour contrôler les facteurs de confusion si le but est de tirer des inférences causales (voir les chapitres 12 et 18 pour une discussion détaillée des conceptions d’étude et des méthodes soutenues par OHDSI pour PLE comme les méthodes visant à éliminer les facteurs de confusion observés en équilibrant les populations sur de nombreuses caractéristiques).

19.0.2 Pré-Spécification de la Conception de l’Étude

La pré-spécification d’une conception d’étude observationnelle et des paramètres est cruciale pour éviter d’introduire un biais supplémentaire en faisant évoluer inconsciemment ou consciemment l’approche pour atteindre un résultat souhaité, parfois appelé p-hacking. La tentation de ne pas spécifier complètement les détails de l’étude à l’avance est plus grande avec l’utilisation secondaire des données qu’avec l’utilisation primaire, car ces données, telles que les DSE et les réclamations, donnent parfois au chercheur un sentiment de possibilités infinies, menant à une ligne d’enquête sinueuse. La clé est donc d’imposer encore la structure rigoureuse de l’enquête scientifique malgré la disponibilité apparemment facile de données préexistantes. Le principe de pré-spécification est particulièrement important dans les PLE ou PLP pour assurer des résultats rigoureux ou reproductibles, car ces résultats peuvent en fin de compte informer les pratiques cliniques ou les décisions réglementaires. Même dans le cas d’une étude de caractérisation menée uniquement à des fins exploratoires, il est tout de même préférable d’avoir un plan bien spécifié. Sinon, une conception d’étude évolutive et un processus d’analyse deviendront ingérables à documenter, expliquer et reproduire.

19.0.3 Protocole

Un plan d’étude observationnelle doit être documenté sous la forme d’un protocole créé avant d’exécuter une étude. A minima, un protocole décrit la question principale de l’étude, l’approche, et les métriques qui seront utilisées pour répondre à la question. La population étudiée doit être décrite avec un niveau de détail tel que la population de l’étude puisse être entièrement reproduite par d’autres. De plus, toutes les méthodes ou procédures statistiques et la forme des résultats attendus de l’étude tels que les métriques, les tableaux et les graphiques doivent être décrits. Souvent, un protocole décrira également un ensemble de pré-analyses conçues pour évaluer la faisabilité ou la puissance statistique de l’étude. En outre, les protocoles peuvent contenir des descriptions de variations sur la question principale de l’étude appelées analyses de sensibilité. Les analyses de sensibilité sont conçues pour évaluer l’impact potentiel des choix de conception de l’étude sur les résultats globaux de l’étude et devraient être décrites à l’avance dans la mesure du possible. Parfois, des problèmes imprévus surviennent qui peuvent nécessiter un amendement du protocole après que celui-ci a été complété. Si cela devient nécessaire, il est crucial de documenter le changement et les raisons du changement dans le protocole lui-même. En particulier dans le cas des PLE ou PLP, un protocole d’étude complété sera idéalement enregistré sur une plateforme indépendante (telle que clinicaltrials.gov ou le bac à sable studyProtocols d’OHDSI) où ses versions et ses amendements peuvent être suivis indépendamment avec des horodatages. Il est également souvent le cas que votre institution ou le propriétaire de la source de données demandera l’opportunité de réviser et d’approuver votre protocole avant l’exécution de l’étude.

19.0.4 Analyses Standardisées

Un avantage unique de l’OHDSI est les moyens par lesquels les outils soutiennent la planification, la documentation et le reporting en reconnaissant qu’il y a vraiment quelques principaux types de questions qui sont posées de manière répétée dans les études observationnelles (chapitres 2, 7, 11, 12, 13), rationalisant ainsi le développement du protocole et le processus de mise en œuvre de l’étude grâce à l’automatisation des aspects qui sont répétés. De nombreux outils sont conçus pour paramétrer quelques conceptions d’études ou métriques qui répondent à la majorité des cas d’utilisation auxquels on sera confronté. Par exemple, les chercheurs spécifient leurs populations d’étude et quelques paramètres supplémentaires et réalisent de nombreuses études comparatives en itérant sur différents médicaments et/ou résultats. Si les questions d’un chercheur s’inscrivent dans le modèle général, il existe des moyens d’automatiser la génération de nombreuses descriptions de bases des populations d’étude et d’autres paramètres requis pour le protocole. Historiquement, ces approches ont été motivées par les expériences OMOP qui cherchaient à évaluer dans quelle mesure les conceptions d’études observationnelles étaient capables de reproduire des liens causaux connus entre les médicaments et les événements indésirables en itérant sur de nombreuses conceptions et paramètres d’études différents.

L’approche OHDSI soutient l’inclusion de la faisabilité et des diagnostics d’étude dans le protocole en permettant à nouveau que ces étapes soient réalisées relativement simplement dans un cadre et des outils communs (voir section 19.1.4 ci-dessous).

19.0.5 Paquets d’Études

Une autre motivation pour les modèles et conceptions standardisés est que même lorsque un chercheur pense qu’une étude est décrite en détail complet sous la forme d’un protocole, il peut y avoir des éléments qui ne sont pas réellement suffisamment spécifiés pour générer le code informatique complet pour exécuter l’étude. Un principe fondamental connexe qui est rendu possible par le cadre OHDSI est de générer un processus complètement traçable et reproductible documenté sous la forme de code informatique, souvent appelé un “paquet d’étude”. La meilleure pratique de l’OHDSI est d’enregistrer un tel paquet d’étude dans l’environnement git. Ce paquet d’étude contient tous les paramètres et les tampons de version pour la base de code. Comme mentionné précédemment, les études observationnelles posent souvent des questions avec un potentiel d’impact sur les décisions de santé publique et la politique. Par conséquent, avant d’agir sur des conclusions, elles devraient idéalement être reproduites dans plusieurs contextes par différents chercheurs. La seule façon d’atteindre un tel objectif est que chaque détail requis pour reproduire entièrement une étude soit explicitement cartographié et non laissé à la devinette ou à la mauvaise interprétation. Pour soutenir cette meilleure pratique, les outils OHDSI sont conçus pour aider à la traduction d’un protocole sous la forme d’un document écrit en un paquet d’étude lisible par un ordinateur ou une machine. Un compromis de ce cadre est que tous les cas d’utilisation ou les analyses personnalisées ne peuvent pas être facilement abordés avec les outils OHDSI existants. À mesure que la communauté grandit et évolue, cependant, plus de fonctionnalités pour aborder un plus grand éventail de cas d’utilisation sont ajoutées. Toute personne impliquée dans la communauté peut suggérer de nouvelles fonctionnalités motivées par un cas d’utilisation novateur.

19.0.6 Les Données Sous-Jacentes au CDM

Les études OHDSI se basent sur des bases de données observationnelles traduites dans le modèle de données commun OMOP (CDM). Tous les outils OHDSI et les étapes d’analyses en aval partent du principe que la représentation des données est conforme aux spécifications du CDM (voir chapitre 4). Il est donc également crucial que le processus ETL (voir chapitre 6) pour ce faire soit bien documenté pour vos sources de données spécifiques car ce processus peut introduire des artefacts ou des différences entre les bases de données à différents sites. Le but du CDM OMOP est de tendre vers la réduction de la représentation spécifique aux sites de données, mais il s’agit loin d’un processus parfait et reste toujours un domaine difficile que la communauté cherche à améliorer. Il reste donc crucial lors de l’exécution des études de collaborer avec des individus sur votre site, ou sur des sites externes lors de l’exécution d’études en réseau, qui sont intimement familiers avec toute source de données qui a été transformée dans le CDM OMOP.

En plus du CDM, le système de vocabulaire standardisé OMOP (chapitre 5) est également un composant critique pour travailler avec le cadre OHDSI pour obtenir l’interopérabilité entre diverses sources de données. Le vocabulaire standardisé cherche à définir un ensemble de concepts standards au sein de chaque domaine de vocabulaire auquel tous les autres systèmes de vocabulaire source sont mappés. De cette façon, deux bases de données différentes qui utilisent un système de vocabulaire source différent pour les médicaments, les diagnostics ou les procédures seront comparables lorsqu’elles seront transformées dans le CDM. Les vocabulaires OMOP contiennent également des hiérarchies qui sont utiles pour identifier les codes appropriés pour une définition de cohorte particulière. Encore une fois, il est recommandé de mettre en œuvre les correspondances de vocabulaire et d’utiliser les codes des vocabulaires standardisés OMOP dans les requêtes en aval afin de bénéficier pleinement de l’ETL de votre base de données dans le CDM OMOP et d’utiliser le vocabulaire OMOP.

19.1 Étapes de l’Étude en Détail

19.1.1 Définir la Question

La première étape consiste à traduire votre intérêt de recherche en une question précise qui peut être abordée par une étude observationnelle. Disons que vous êtes un chercheur clinique en diabète et que vous souhaitez enquêter sur la qualité des soins offerts aux patients atteints de diabète sucré de type 2 (T2DM). Vous pouvez décomposer cet objectif plus large en questions beaucoup plus spécifiques qui appartiennent à l’un des trois types de questions décrites pour la première fois au Chapitre 7.

Dans une étude de caractérisation, on pourrait se demander, “les pratiques de prescription sont-elles conformes aux recommandations actuelles pour les patients atteints de T2DM léger par rapport à ceux atteints de T2DM sévère dans un environnement de soins donné ?” Cette question ne pose pas une question causale sur l’efficacité d’un traitement donné par rapport à un autre ; elle se contente de caractériser les pratiques de prescription dans votre base de données par rapport à un ensemble de lignes directrices cliniques existantes.

Peut-être êtes-vous également sceptique quant à savoir si les lignes directrices de prescription pour le traitement du T2DM sont les meilleures pour un sous-ensemble particulier de patients tels que ceux ayant à la fois un diagnostic de T2DM et une maladie cardiaque. Cette ligne de questionnement peut être traduite en une étude PLE. Plus précisément, vous pouvez poser une question sur l’efficacité comparative de 2 classes de médicaments contre le T2DM dans la prévention des événements cardiovasculaires, tels que l’insuffisance cardiaque. Vous pourriez concevoir une étude pour examiner les risques relatifs d’hospitalisation pour insuffisance cardiaque dans deux cohortes de patients prenant des médicaments différents, mais où les deux cohortes ont un diagnostic de T2DM et de maladie cardiaque.

Alternativement, vous souhaiterez peut-être développer un modèle pour prédire quels patients passeront d’un T2DM léger à un T2DM sévère. Cela peut être formulé comme une question PLP et pourrait servir à signaler les patients à risque accru de transition vers un T2DM sévère pour un suivi plus vigilant.

D’un point de vue purement pragmatique, définir une question d’étude nécessite également d’évaluer si les approches nécessaires pour répondre à la question correspondent aux fonctionnalités disponibles dans l’ensemble d’outils OHDSI (voir Chapitre 7 pour une discussion détaillée des types de questions pouvant être abordées avec l’outil actuel). Bien sûr, il est toujours possible de concevoir vos propres outils analytiques ou de modifier ceux actuellement disponibles pour répondre à d’autres questions.

19.1.2 Examiner la Disponibilité et la Qualité des Données

Avant de vous engager dans une question d’étude particulière, il est recommandé d’examiner la qualité des données (voir Chapitre 15) et de bien comprendre la nature de votre base de données de soins de santé observationnelle particulière en termes de champs remplis et de ce que couvrent les données en termes de paramètres de soins. Cela peut aider à identifier rapidement des problèmes qui pourraient rendre une question d’étude irréalisable dans une base de données particulière. Ci-dessous, nous soulignons certains problèmes courants qui peuvent survenir.

Revenons à l’exemple ci-dessus de développement d’un modèle de prédiction de la progression d’un T2DM léger à un T2DM sévère. Idéalement, la sévérité du T2DM pourrait être évaluée en examinant les niveaux d’hémoglobine glycosylée (HbA1c), qui est une mesure de laboratoire reflétant les niveaux de sucre dans le sang d’un patient en moyenne sur les trois mois précédents. Ces valeurs peuvent ou non être disponibles pour tous les patients. Si elles ne sont pas disponibles pour une partie ou l’ensemble des patients, vous devrez envisager de savoir si d’autres critères cliniques de sévérité du T2DM peuvent être identifiés et utilisés à la place. Alternativement, si les valeurs HbA1c sont disponibles uniquement pour un sous-ensemble de patients, il vous faudra également évaluer si se concentrer uniquement sur ce sous-ensemble de patients entraînerait un biais indésirable dans l’étude. Voir le Chapitre 7 pour une discussion supplémentaire sur le problème des données manquantes.

Un autre problème courant est l’absence d’informations sur un cadre de soins particulier. Dans l’exemple PLE décrit ci-dessus, le résultat suggéré était l’hospitalisation pour insuffisance cardiaque. Si une base de données donnée ne contient aucune information sur les patients hospitalisés, il pourrait être nécessaire de considérer un résultat différent pour évaluer l’efficacité comparative des différentes approches de traitement du T2DM. Dans d’autres bases de données, les données de diagnostic en consultation externe peuvent ne pas être disponibles et, par conséquent, il faudrait considérer la conception de la cohorte.

19.1.3 Populations d’Étude

Définir une population d’étude ou des populations est une étape fondamentale de toute étude. Dans la recherche observationnelle, un groupe d’individus représentatifs de la population d’étude d’intérêt est souvent appelé cohorte. Les caractéristiques des patients requises pour la sélection dans une cohorte seront déterminées par la population d’étude pertinente pour la question clinique en jeu. Un exemple de cohorte simple serait des patients âgés de plus de 18 ans ET ayant un code de diagnostic pour T2DM dans leur dossier médical. Cette définition de cohorte comporte deux critères connectés par la logique ET. Souvent, les définitions de cohorte contiennent beaucoup plus de critères connectés par une logique booléenne plus complexe et des critères temporels supplémentaires tels que des périodes d’étude spécifiques ou des durées de temps requises pour la période de référence d’un patient.

Un ensemble raffiné de définitions de cohorte nécessite l’examen de la littérature scientifique appropriée et des conseils d’experts cliniques et techniques qui comprennent certains des défis d’interprétation de votre base de données spécifique pour identifier des groupes de patients appropriés. Il est important de garder à l’esprit que les données observationnelles ne fournissent pas une image complète des antécédents médicaux d’un patient, mais plutôt une instantané dont la fidélité est soumise à l’erreur humaine et au biais qui peuvent avoir été introduits lors de l’enregistrement de l’information. Un patient donné peut n’être suivi que pour une période finie appelée sa période d’observation. Pour une base de données ou un cadre de soins donné et une maladie ou un traitement étudié, un chercheur clinique peut être en mesure de faire des suggestions pour éviter les sources d’erreurs les plus courantes. Pour donner un exemple simple, un problème courant pour identifier les patients atteints de T2DM est que les patients atteints de T1DM sont parfois incorrectement codés avec un diagnostic de T2DM. Parce que les patients atteints de T1DM représentent un groupe fondamentalement différent, l’inclusion non intentionnelle d’un groupe de patients atteints de T1DM dans une étude censée examiner des patients atteints de T2DM pourrait biaiser les résultats. Afin d’avoir une définition robuste d’une cohorte T2DM, on peut vouloir éliminer les patients qui n’ont jamais reçu que de l’insuline comme traitement du diabète pour éviter que des patients atteints de T1DM ne soient représentés par erreur. En même temps, cependant, il peut également y avoir des situations où l’on s’intéresse simplement aux caractéristiques de tous les patients ayant un code de diagnostic T2DM dans leur dossier médical. Dans ce cas, il peut ne pas être approprié d’appliquer d’autres critères qualificatifs pour tenter d’éliminer les patients atteints de T1DM mal codés.

Une fois que la définition d’une ou des populations d’étude est décrite, l’outil OHDSI ATLAS est un bon point de départ pour créer les cohortes pertinentes. ATLAS et le processus de génération de cohortes sont décrits en détail dans les Chapitres 8 et 10. En bref, ATLAS fournit une interface utilisateur (UI) pour définir et générer des cohortes avec des critères d’inclusion détaillés. Une fois les cohortes définies dans ATLAS, un utilisateur peut exporter directement leurs définitions détaillées au format lisible par l’humain pour les intégrer à un protocole. Si pour une raison quelconque une instance ATLAS n’est pas connectée à une base de données de santé observationnelle, ATLAS peut toujours être utilisé pour créer une définition de cohorte et exporter directement le code SQL sous-jacent pour l’intégrer à un paquet d’étude à exécuter séparément sur un serveur de base de données SQL. L’utilisation directe d’ATLAS est recommandée lorsque cela est possible, car ATLAS offre certains avantages au-delà de la création de code SQL pour la définition de cohorte (voir ci-dessous). Enfin, il peut y avoir certaines rares situations où une définition de cohorte ne peut pas être implantée avec l’UI d’ATLAS et nécessite un code SQL personnalisé manuel.

L’interface utilisateur d’ATLAS permet de définir des cohortes sur la base de nombreux critères de sélection. Les critères d’entrée et de sortie de la cohorte, ainsi que les critères de référence, peuvent être définis en fonction de n’importe quel domaine du CDM OMOP tels que les conditions, les médicaments, les procédures, etc., où des codes standards doivent être spécifiés pour chaque domaine. De plus, des filtres logiques fondés sur ces domaines, ainsi que des filtres basés sur le temps pour définir des périodes d’étude et des durées de référence, peuvent être définis dans ATLAS. ATLAS peut être particulièrement utile lors de la sélection de codes pour chaque critère. ATLAS intègre une fonctionnalité de navigation par vocabulaire qui permet de construire des ensembles de codes nécessaires à vos définitions de cohorte. Cette fonctionnalité repose uniquement sur les vocabulaires standard OMOP et propose des options pour inclure tous les descendants dans la hiérarchie des vocabulaires (voir Chapitre 5). Notez donc que cette fonctionnalité nécessite que tous les codes aient été correctement mappés aux codes standards lors du processus ETL (voir Chapitre 6). Si les ensembles de codes les plus appropriés à utiliser dans vos critères d’inclusion ne sont pas clairs, cela peut être un point où une analyse exploratoire peut être justifiée dans les définitions de cohorte. Alternativement, une analyse de sensibilité plus formelle pourrait être envisagée pour tenir compte des différentes définitions possibles d’une cohorte utilisant différents ensembles de codes.

À supposer que ATLAS soit configuré de manière appropriée pour se connecter à une base de données, des requêtes SQL pour générer les cohortes définies peuvent être exécutées directement dans ATLAS. ATLAS attribuera automatiquement une id unique à chaque cohorte qui peut également être utilisée pour référencer directement la cohorte dans la base de données de backend pour utilisation future. La cohorte peut être utilisée directement dans ATLAS pour exécuter une étude de taux d’incidence ou elle peut être pointée directement dans la base de données par un code dans un paquet d’étude PLE ou PLP. Pour une cohorte donnée, ATLAS enregistre uniquement les identifiants des patients, les dates d’index et les dates de sortie de cohorte des individus dans les cohortes. Ces informations sont suffisantes pour dériver tous les autres attributs ou covariables qui peuvent être nécessaires pour les patients tels que les covariables de référence des patients pour une étude de caractérisation, PLE ou PLP.

Lorsqu’une cohorte est créée, des caractéristiques sommaires des données démographiques des patients et des fréquences des médicaments et des conditions les plus fréquents observés peuvent être créées et visualisées par défaut directement dans ATLAS.

En réalité, la plupart des études nécessitent la spécification de plusieurs cohortes ou ensembles de cohortes multiples qui sont ensuite comparés de différentes manières pour obtenir de nouvelles compréhensions cliniques. Pour les PLE et PLP, les outils OHDSI fournissent un cadre structuré pour définir ces multiples cohortes. Par exemple, dans une étude d’efficacité comparative PLE, vous définirez généralement au moins 3 cohortes : une cohorte cible, une cohorte comparateur et une cohorte de résultats (voir Chapitre 12). De plus, pour exécuter une étude complète d’efficacité comparative PLE, vous aurez également besoin d’un certain nombre de cohortes avec des résultats de contrôle négatifs et des résultats de contrôle positifs. La suite d’outils OHDSI propose des moyens pour aider à accélérer et, dans certains cas, à automatiser la génération de ces cohortes de contrôle négatif et positif, comme discuté en détail dans le Chapitre 18.

Enfin, définir des cohortes pour une étude peut bénéficier des travaux en cours dans la communauté OHDSI pour définir une bibliothèque de phénotypes robustes et validés, où un phénotype est essentiellement une définition de cohorte exportable. Si l’une de ces définitions de cohorte existantes est appropriée pour votre étude, les définitions exactes peuvent être obtenues en important un fichier json dans votre instance ATLAS.

19.1.4 Faisabilité et Diagnostics

Une fois les cohortes définies et générées, un processus plus formel pour examiner la faisabilité de l’étude dans les sources de données disponibles peut être entrepris et les résultats résumés dans le protocole finalisé. L’évaluation de la faisabilité de l’étude peut englober un certain nombre d’activités exploratoires et parfois itératives. Nous décrivons ici quelques aspects courants.

Une activité principale à ce stade sera de passer en revue de manière approfondie les distributions des caractéristiques au sein de vos cohortes pour vous assurer que la cohorte que vous avez générée est conforme aux caractéristiques cliniques souhaitées et signaler toute caractéristique inattendue. Pour revenir à notre exemple T2DM ci-dessus, en caractérisant cette simple cohorte T2DM en examinant les fréquences de tous les autres diagnostics reçus, on pourrait être en mesure de signaler la question de capture également de patients atteints de T1DM ou d’autres problèmes non anticipés. Il est de bonne pratique d’intégrer une telle étape de caractérisation initiale de toute nouvelle cohorte dans le protocole d’étude en tant que contrôle qualitatif de la validité clinique de la définition de la cohorte. En termes de mise en œuvre, la manière la plus simple de réaliser un premier passage consiste à examiner la démographie de la cohorte et les principaux médicaments et conditions qui peuvent être générés par défaut lors de la création d’une cohorte dans ATLAS. Si l’option de créer les cohortes directement dans ATLAS n’est pas disponible, des requêtes SQL manuelles ou l’utilisation du package d’extraction de fonctionnalités R peuvent être utilisées pour caractériser une cohorte. En pratique, dans une étude PLE ou PLP plus large, ces étapes peuvent être intégrées au paquet d’étude avec des étapes d’extraction des fonctionnalités.

Une autre étape courante et importante pour évaluer la faisabilité pour un PLE ou un PLP est une évaluation des tailles de cohorte et des nombres de résultats dans les cohortes cible et comparateur. La fonctionnalité de taux d’incidence d’ATLAS peut être utilisée pour trouver ces dénombrements qui peuvent être utilisés pour réaliser des calculs de puissance comme décrit ailleurs.

Une autre option qui est fortement recommandée pour une étude PLE est de compléter les étapes de correspondance des scores de propension (PS) et les diagnostics pertinents pour s’assurer qu’il y a un chevauchement suffisant entre les populations dans les groupes cible et comparateur. Ces étapes sont décrites en détail au Chapitre 12. De plus, en utilisant ces cohortes appariées finales, la puissance statistique peut ensuite être calculée.

Dans certains cas, le travail dans la communauté OHDSI examine la puissance statistique uniquement après qu’une étude soit menée, en rapportant un risque relatif minimal détectable (MDRR) donné les tailles d’échantillon disponibles. Cette approche peut être plus utile lors de l’exécution d’études automatisées à haut débit sur de nombreuses bases de données et sites. Dans ce scénario, la puissance d’une étude dans une base de données donnée est peut-être mieux explorée après que toutes les analyses ont été réalisées plutôt qu’avant le filtrage.

19.1.5 Finaliser le Protocole et le Paquet d’Étude

Une fois le travail préparatoire pour toutes les étapes précédentes terminé, un protocole final doit être assemblé incluant des définitions de cohorte détaillées et des informations sur la conception de l’étude idéalement exportées depuis ATLAS. En annexe 23.2, nous fournissons un modèle de table des matières pour un protocole complet d’étude PLE. Cela peut également être trouvé sur le github OHDSI. Nous fournissons cet exemple comme un guide complet et une liste de contrôle, mais notons que certaines sections peuvent ou non être pertinentes pour votre étude.

Comme illustré à la Figure ??, l’assemblage du protocole d’étude final sous une forme lisible par l’homme doit être effectué en parallèle avec la préparation de tout le code d’étude lisible par machine qui est intégré au paquet d’étude final. Ces dernières étapes sont appelées mise en œuvre de l’étude dans le diagramme ci-dessous. Cela inclura l’exportation du paquet d’étude finalisé d’ATLAS et/ou le développement de tout code personnalisé qui pourrait être nécessaire.

Le paquet d’étude complété peut ensuite être utilisé pour exécuter uniquement les étapes de diagnostics préliminaires qui à leur tour peuvent être décrites dans le protocole. Par exemple, dans le cas d’une étude de cohorte de nouveaux utilisateurs PLE pour examiner l’efficacité comparative de deux traitements, l’exécution préliminaire des étapes de diagnostics d’étude nécessitera la création de cohortes, la création de scores de propension et l’appariement pour confirmer que les populations cible et comparateur ont un chevauchement suffisant pour que l’étude soit faisable. Une fois cela déterminé, des calculs de puissance peuvent être effectués avec les cohortes appariées cible et comparateur intersectées avec la cohorte de résultats pour obtenir des nombres de résultats et les résultats de ces calculs peuvent être décrits dans le protocole. Sur la base de ces résultats diagnostics, une décision peut être prise pour déterminer ou non la poursuite de la modélisation finale des résultats. Dans le contexte d’une étude de caractérisation ou d’une étude PLP, il peut y avoir des étapes similaires qui doivent être complétées à ce stade, bien que nous ne tentions pas d’énumérer tous les scénarios ici.

Il est important à cette étape de faire examiner votre protocole finalisé par des collaborateurs cliniques et des parties prenantes.

```{r studyProcess, fig.cap=“Diagram of the study process.”, echo=FALSE, out.width=‘90%’, fig.align ## Résumé

L’étude doit examiner une question bien définie.
Effectuer des vérifications appropriées de la qualité, de l’exhaustivité et de la pertinence des données à l’avance.
Recommander d’inclure un expert de la base de données source dans le processus de développement du protocole si possible.
Documenter l’étude proposée dans un protocole à l’avance.
Générer le code du paquet d’étude en parallèle avec le protocole écrit et effectuer et décrire toute faisabilité et diagnostic avant d’exécuter l’étude finale.
L’étude doit être enregistrée et approuvée (si nécessaire) avant l’exécution de l’étude.
Le rapport final ou le manuscrit doit être revu par des experts cliniques et d’autres parties prenantes.