Le CDISC (Clinical Data Interchange Standards Consortium) est un consortium international à but non lucratif qui vise à promouvoir la standardisation des formats de recueil, d'échange, de soumission et d'archivage de données dans la recherche clinique.
Comme chacun sait, la standardisation dans le traitement des données tend à accélérer l'ensemble des processus liés à la recherche, et donc d'en réduire les coûts.
L'objectif de CDISC est de fluidifier la circulation des données depuis le dossier patient jusqu'à l'analyse statistique et l'archivage, au travers des différentes étapes et des logiciels qui leurs sont associés.
CDISC publie donc une série de standards, pour :
- Modéliser / Organiser : BRIDG, PRM, SDM
- Recueillir : CDASH, Lab
- Echanger (et archiver) : ODM
- Soumettre les données aux autorités de santé (pour l'obtention d'une AMM, par exemple) : SDTM (avec Define), SEND
- Présenter l’analyse des données à ces mêmes autorités : ADaM
L'adoption des standards CDISC permet donc :
- Une harmonisation des formats de variables et des outils de recueil
- La facilitation des échanges de données entre différents systèmes d’information (par exemple Dossier Patient Electronique et eCRF)
- Un archivage des eCRF à long terme, dans un format ouvert xml
- Une soumission des données de la recherche aux autorités de santé dans des formats stricts, leur permettant de retrouver par elles-mêmes les résultats amenés à être publiés (obligatoire pour la FDA aux USA dès 2017)
- D’avantage d’indépendance vis-à-vis des éditeurs de logiciels
- Etc.
CDISC s'appuie pour beaucoup sur le format xml ; une connaissance approfondie de ce format est donc recommandée pour mieux appréhender l'utilisation de l'ensemble des standards CDISC.
Le format xml permet d'enregistrer des données de manière structurée, mais sous forme de texte. Il s'agit d'un format non propriétaire, contrairement à des formats de type xls ou pdf, ce qui en fait un bon candidat pour la conservation de données à long terme.
Brièvement, ce format repose sur l'utilisation de balises pour délimiter une variable, ou un groupe de variables.
Prenons l'exemple d'une table très simple contenant une liste de contacts, avec leurs noms, prénoms et e-mails :
NOM | PRENOM | |
Dupont | Jean | |
Dupuis | Eveline |
Dans un fichier xml, ces informations pourraient prendre par exemple la forme suivante :
<?xml version="1.0" encoding="UTF-8"?>
<REPERTOIRE>
<CONTACT>
<NOM>Dupont</NOM>
<PRENOM>Jean</PRENOM>
<E-MAIL>jean.dupont@caramail.com</E-MAIL>
</CONTACT>
<CONTACT>
<NOM>Dupuis</NOM>
<PRENOM>Eveline</PRENOM>
<E-MAIL>e.dupuis@yahoo.fr</E-MAIL>
</CONTACT>
</REPERTOIRE>
La première ligne est appelée "déclaration xml" ; elle informe le logiciel qui ouvre le fichier qu'il s'agit d'un fichier de type xml.
<NOM>Dupuis</NOM> est un "élément" xml simple, constitué d'une "balise ouvrante" <NOM>, d'un "contenu" prenant la valeur Dupuis, et d'une "balise fermante" </NOM>.
L'élément CONTACT est un élément xml complexe, constitué des éléments NOM, PRENOM et E-MAIL.
REPERTOIRE est l'élément "racine" du document xml, constitué de plusieurs éléments CONTACT.
Il est possible d’apporter des informations supplémentaires sur un élément xml par l’utilisation d’un "attribut", se trouvant àl’intérieur de la balise ouvrante.
Dans l’élément ci-dessous, l’attribut "SubjectKey" précise que les données concernent le patient ayant la référence 001-0001-A-B :
<SubjectData SubjectKey="001-0001-A-B">...</SubjectData>.
Un document xml contenant des données (le document principal) est habituellement accompagné d'un document annexe appelé "schéma", lui-même ayant un format de type xml mais portant l'extension xsd, et dans lequel sont définis les types d'éléments que l'on peut rencontrer dans le document xml principal et leurs inter-relations. Voici le type d'élément que l'on peut trouver dans un schéma xsd :
<xs:element name="NOM"type="xs:string" />.
Il est signifié ici que le contenu entre deux balises NOM doit être de type texte (string), par exemple Dupont, Dupuis...
Ainsi, un schéma sert-il à "valider" le fichier xml contenant les données.
BRIDG (Biomedical Research Integrated Domain Group)
L'objectif de BRIDG est de permettre une représentation universelle de la sémantique commune spécifique à la Recherche Clinique.
L'idée de base est la suivante : pour que des systèmes puissent communiquer (par exemple un dossier patient électronique et un cahier d'observation électronique), ils doivent parler le même langage ; une même expression doit désigner la même notion.
Ce standard se concrétise par une modélisation cartographique d’un protocole de recherche clinique, sous forme d'une série de diagrammes au format UML (Unified Modeling Language), un format standard, couramment utilisé pour établir les spécifications nécessaires au bon développement d'un logiciel.
BRIDG permet ainsi de visualiser graphiquement les différentes étapes et les différents flux de données de la recherche pour mieux élaborer les standards de communication Recherche/Recherche ou Recherche/Soins.
La sémantique de BRIDG s'appuie entre autre sur HL7 (Health Level 7), standard de spécifications techniques pour les échanges informatisés de données cliniques, financières et administratives entre Systèmes d'Information de soins.
PRM (Protocol Representation Model)
PRM est en quelque sorte une "sous-partie" de BRIDG, focalisée sur différents éléments du protocole et les relations qui les unissent :
- (Typologie) (Design) de la recherche en termes de Timing, de groupes (bras)…
- Types de rôles joués par les intervenants
- Critères d’éligibilité
- Données nécessaires à l’enregistrement (sur ClinicalTrials.gov par exemple)
Ce n'est pas un protocole-type, mais un outil d’aide à la conception du protocole et à la création de documents, en facilitant son informatisation.
CDASH (Clinical Data Aquisition Standard Harmonization)
Le CDASH a pour objectif de standardiser le recueil des données sur les CRF (électroniques ou papiers). Il se présente comme un guide de bonnes pratiques, suggérant les données à recueillir, en évaluant leur pertinence et en explicitant la manière de les collecter pour faciliter au mieux leur traitement.
Le but est de réduire la variabilité entre les CRF, en particulier en réutilisant les mêmes libellés et les mêmes définitions de variables.
LAB (Laboratory Standards)
Ce standard a pour but de faciliter l’intégration des données issues des laboratoires d'analyse dans les bases de données de la recherche, en définissant notamment les prérequis nécessaires à leur incorporation dans l’ODM.
Ces données sont regroupées en 12 grandes catégories.
LAB utilise, pour identifier les résultats des tests biologiques ou des observations cliniques, la nomenclature LOINC (pour Logical Observation Identifiers Names and Codes).
ODM (Operational Data Model)
Standard pour l’acquisition, l’échange et l’archivage des données cliniques.
L'idée est de conserver dans un même fichier toutes les données d'une recherche, telles qu'elles sont recueillies dans les cahiers d'observation, dans un format structuré (xml), ouvert, pouvant être lu par n'importe quel logiciel.
Un fichier xml ODM contient les données elles-mêmes, et les informations nécessaires à la définition et à la restitution de ces données (méta-données de l'étude et administratives).
SDM (Study Design Model)
Il ne s'agit pas d'un standard à part entière, mais d'une série de fragments d'information, d'arborescences xml, que l'on peut rajouter dans un fichier ODM (partie Métadonnées / Protocole), identifiables par une balise spécifique.
SDM est focalisé sur la description d'une recherche dans sa globalité, et contient des données telles que le titre et la phase de la recherche, ses objectifs, son design (parallèle, cross over...), le nombre de sujets, les critères d'éligibilités, le calendrier...mais en aucun cas les données cliniques du sujet ; SDM décrit comment la recherche doit se dérouler, non comment la recherche s'est déroulée réellement pour chaque patient.
On peut utiliser des fichiers ODM partiels, contenant juste la partie "Study" (Métadonnées sur le Protocole), avec les fragments SDM, pour transférer le descriptif d'une recherche entre deux Systèmes d'Information, par exemple.
On peut également dériver de SDM certains domaines de SDTM (voir ci-après), comme TS (pour Trial Summary) ou TI (pour Trial Inclusion Exclusion Criteria).
SDTM (Study Data Tabulation Model) et Define
SDTM est le standard de soumission des données de la recherche aux autorités de santé (tel que la FDA).
Il définit une structure standard de stockage de données, sous forme de plusieurs tables, accompagnées d'un fichier xml décrivant les variables (métadonnées), appelé Define.xml. Les tables elles-mêmes sont au format SAS transport (SAS v5), ou xml.
L'un des grands principes de ce standard est de regrouper les données par "Domaines" et par thème (Adverse Event, Demographics, Concomitant Medications…).
Le SDTM définit une recherche comme une série d’observations, une observation étant une série de variables.
Trois grandes classes d'observations sont ainsi définies :
- Interventions : ce qui est fait sur un sujet (administration d'un traitement, par exemple)
- Events : un évènement de la recherche (inclusion, randomisation…)
- Findings : les tests et évaluations faites sur le sujet (données cliniques tel que le pouls, le poids…, données de laboratoire comme la glycémie, etc.)
5 types de variables sont également décrits :
- Identifier : telles que celles identifiant l’étude, le sujet impliqué dans l’étude, le domaine, le numéro d’enregistrement
- Topic : qui spécifie la teneur de l’observation
- Timing : dates, heures…
- Qualifier : contribuant à préciser le résultat (les unités par exemple)
- Rule : précisant la périodicité.
SEND (Standard for Exchange of Nonclinical Data)
SEND est un standard basé sur SDTM.
Il en reprend les principes généraux en termes de structuration des données, mais se focalise sur les données NON cliniques, c'est à dire sur les données des études précliniques : le "sujet" de la recherche est ici un animal.
Un certain nombre de domaines spécifiques à ces études sont donc rajoutés, tels que les données de pharmacocinétique (Pharmacokinetics Parameters).
ADaM (Analysis Dataset Model)
Il s'agit d'un standard de soumission des données d’analyse statistique aux organismes réglementaires comme la FDA.
Comme SDTM, ou SEND, il prend la forme d'une série de tables (au format SAS transport).
Les données y sont organisées de manière à être immédiatement intégrables et analysables par des logiciels de statistique comme SAS.
La table ADSL (Subject-Level Analysis Dataset) contient un enregistrement par sujet, incluant des données de traitements, démographie, randomisation, certaines dates clés, etc.
La table BDS (Basic Data Structure) contient un ou plusieurs enregistrement(s) par sujet, incluant la description des paramètres d’analyse statistique, les valeurs des données d’analyses, etc.
Les métadonnées décrivant le contenu de la collection de données d’analyse ci-dessus, et la manière dont elles ont été générées à partir des données source au format SDTM, sont également enregistrées sous forme des tables.
SHARE (Shared Health and Research Electronic Library)
Il s'agit d'un projet de bibliothèque électronique de métadonnées au format CDISC.