Simplifications

Le mandat est de proposer des modifications à la plateforme de DataShapper afin d'en simplifier l'utilisation et la rendre plus accessible. Nous présentons ici les conclusions de nos discussions et quelques recommendations.

Séparer DataSchema d'Harmonisation et DataSchema Prospectifs

Présentement, la plateforme des DataSchema est utilisée pour décrire les variables d'un processus d'harmonisation de plusieurs datasets et pour décrire des variables "best practice" de manière à harmoniser des datasets à priori.

Les 2 façon d'utiliser la plateforme force à modéliser les variables (leurs attributs, dimensions etc.) afin de couvrir l'union des besoins. Ceci créer de la confusion lorsque vient le temps de comprendre la plateforme, car elle sert 2 besoins, au fond, très différents. Par exemple, lors de l'harmonisation, il est important d'indiquer comment une variable a été collectée (mesure directe, questionnaire, dossier médical) alors que pour une variable "prospective" cette information est superflue et porte même à confusion.

Il serait donc avantageux de séparer la plateforme d'harmonisation rétrospective de la plateforme d'harmonisation prospective. On parlera alors de la partie harmonisation vs. la partie "science".

DataSchema pour l'harmonisation

La plateforme actuelle de DataSchema ne servira qu'à faire de l'harmonisation restrospective (sur des données ou dictionnaires existants).

Si on nous demande la question "Pourquoi fait-on un DataSchema" la réponse sera toujours "pour faire de l'harmonisation".

Voici quelques conclusions que nous avons tirées de nos discussions (matière à discuter):

• Un utilisateur fait un DataSchema seulement pour harmoniser des données ou des dictionnaires existants
• Un DataSchema se fait dans un contexte de question scientifique (précise ou large) et afin d'harmoniser des données existantes (ou bientôt existantes)
• Pour la science (le prospectif), ce sont des variables qui sont utiles pour de nouvelles études qui se demandent comment couvrir un domaine scientifique (experts du domaine qui le préparent)
• La nature et l'utilité d'un lien entre les variables de DataSchema et les variables prospectives n'est pas clair. Il pourrait y en avoir.
• Garde-t-on la même nomenclature pour une variable prospective et une variable d'harmonisation ?

Réutilisation des variables

Ceci ne traite que la réutilisation de variables dans le context d'harmonisation (pas le côté science/prospectif)

Une des grandes utilités du principe d'harmonisation est la capacité de réutiliser les variables d'un DataSchema dans un autre. Par contre, le système actuel permet de redéfinir certaines choses ce qui rend la réutilisation complexe et difficile à implémenter techniquement.

Voici nos conclusions:

• Quand on réutilise une variable c'est pour utiliser le travail d'harmonisation déjà accomplis (sur d'autres études)
• On ne réutilise pas les variables prospectives dans un DataSchema (mais peut-être elles peuvent servir de template)
• Lorsqu'on utilise une variable d'un autre DataSchema, on l'utilise telle quelle, pour toujours (même si elle change dans l'autre); on peut toujours l'enlever plus tard. Sinon on doit en faire une copie afin de l'ajuster à ses besoins.
• On ne gère pas les liens entre les versions de variables, pcq le système devient trop complexe

Categorisation

La structure actuelle (Module/Thème/Domaine) de variables serait transformée en une catégorisation. Celle-ci deviendrait la catégorisation P3G et s'appliquerait aux variables côté science. On pourrait aussi classifier les variables du côté harmonisation de la même manière, mais ceci serait plus nécessaire.

Cette solution permet aussi de créer d'autres catégorisation (ontologies ou vocabulaires contrôlés existants). Ce qui permet aux utilisateurs de catégoriser selon leurs besoins (catégorisation ad-hoc) plutôt que dans une structure pré-définie.

Variable structure comparison

Some of the dimensions does not make sens for prospective variable like Collection mode or Source of information.

Dimensions

Existing dimensions

• Format: Categorical, Open
• Class: Age, Age of onset, Date/time, Frequency, Identification, Localization, Occurence, etc.
• Type: Date, Decimal, Integer, Text, Time
• Target: Instrument, Interviewer/nurse, Participant, Participant relative(s), etc.
• Target gender: Male, Female
• Period: Currently, In the past, Through all life
• Sample: Buffy coat, Plasma, Red blood cells, Saliva, Serum, Urine
• Source of information: Clinical records, Instrument, Interviewer/nurse, Participant, Participant relative(s), etc.
• Collection mode: Direct measure, Inventory, Questionnaire
• Disease
• Medical health intervention: Therapeutic intervention on the digestive system, Colon polypectomy, etc.

New dimensions imported from keywords tree

http://www.p3gobservatory.org/Observatory.html#QUESTIONNAIRE_KEYWORDS

• Health Information: Medication Intake (ATC/DDD), Women's health, Reproductive history, Participants Early Life Conditions
  We extracted "Medical health intervention" from this vocabulary and already use it in the existing dimensions.
• Individual Disease history (extracted from Health Information)
• Familial Disease History (extracted from Health Information)?
• Body structure: Eye, Hair, Skin, etc.
• Body functions: Memtal functions, Sensory functions and pain, Voice and speech functions, etc.
• Life habits/behaviours: Tobacco use, Alcohol use, Nutrition, Physical activity, etc.
• Sociodemographic Characteristics: Age/Birth Date, Birth location, Ethnicity/Race, etc.
• Socioeconomic Characteristics: Education level, Income, Working status, etc.
• Physical Environment: Occupational Exposures, Environmental exposures, Early life and in utero exposures, etc.
• Social Environment: Familial and social environment, Working Social Environment

Example for variable 'Type of cancer'