Schéma OMOP v5.4
Source : OHDSI Common Data Model v5.4
Cliquez sur une table pour voir sa documentation complète.
PERSON
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
person_id |
On suppose que chaque personne avec un identifiant unique différent est en fait une personne différente et que les données de deux personnes différentes ne doivent pas être combinées. | Toute liaison de personnes nécessaire pour identifier de manière unique les Personnes doit être effectuée avant l'écriture de cette table. Cet identifiant peut être l'id original des données source s'il s'agit d'un entier, sinon il peut être un numéro auto-généré. | integer | Oui | PK | - | - | - |
gender_concept_id |
Ce champ est destiné à capturer le sexe biologique à la naissance de la Personne. Ce champ ne doit pas être utilisé pour étudier les questions d'identité de genre. | Utilisez la valeur de genre présente dans les données en supposant qu'il s'agit du sexe biologique à la naissance. Si les données source capturent l'identité de genre, elle doit être stockée dans la table OBSERVATION. | integer | Oui | - | FK | CONCEPT | Gender |
year_of_birth |
Calculez l'âge en utilisant year_of_birth. | Pour les sources de données avec date de naissance, l'année doit être extraite. Si aucune année de naissance n'est disponible, supprimez les données de la personne de l'instance CDM. | integer | Oui | - | - | - | - |
month_of_birth |
- | Pour les sources de données qui fournissent la date de naissance précise, le mois doit être extrait et stocké dans ce champ. | integer | Non | - | - | - | - |
day_of_birth |
- | Pour les sources de données qui fournissent la date de naissance précise, le jour doit être extrait et stocké dans ce champ. | integer | Non | - | - | - | - |
birth_datetime |
Ce champ n'est pas requis mais fortement recommandé. | Pour les sources de données qui fournissent la date et l'heure précises de naissance, cette valeur doit être stockée dans ce champ. | datetime | Non | - | - | - | - |
race_concept_id |
Ce champ capture l'origine ethnique de la personne. | N'utilisez ce champ que si vous avez des informations sur l'origine ethnique disponibles dans les données source. Les origines mixtes ne sont actuellement pas supportées. Si une personne a plus d'une origine enregistrée, mettez Concept_Id 0. | integer | Oui | - | FK | CONCEPT | Race |
ethnicity_concept_id |
Ce champ capture l'Ethnicité telle que définie par l'OMB : "Hispanic" ou "Not Hispanic". | Ce champ ne doit être utilisé que pour les sources de données basées aux États-Unis. Ne pas déduire l'ethnicité de la race. | integer | Oui | - | FK | CONCEPT | Ethnicity |
location_id |
Ce champ représente la dernière localisation connue de la personne. | Mettez le location_id de la table LOCATION représentant l'information de localisation la plus précise pour la personne. | integer | Non | - | FK | LOCATION | - |
provider_id |
Ce champ représente le dernier médecin traitant connu (médecin généraliste). | Mettez le provider_id de la table PROVIDER du dernier médecin traitant connu. | integer | Non | - | FK | PROVIDER | - |
care_site_id |
Ce champ représente l'établissement de soins où le prestataire fournit habituellement des soins. | - | integer | Non | - | FK | CARE_SITE | - |
person_source_value |
Utilisez ce champ pour faire le lien avec les personnes dans les données source. | Ce champ permet de stocker la valeur de la personne telle qu'elle apparaît dans la source. Non requis mais fortement recommandé. | varchar(50) | Non | - | - | - | - |
gender_source_value |
Ce champ est utilisé pour stocker le sexe biologique de la personne à partir des données source. | Mettez le sexe biologique tel qu'il apparaît dans les données source. | varchar(50) | Non | - | - | - | - |
gender_source_concept_id |
En raison du petit nombre d'options, ce champ tend à être zéro. | Si les données source codent le sexe biologique dans un vocabulaire supporté par OMOP, stockez le concept_id ici. | integer | Non | - | FK | CONCEPT | - |
race_source_value |
Ce champ est utilisé pour stocker l'origine ethnique de la personne à partir des données source. | Mettez l'origine ethnique telle qu'elle apparaît dans les données source. | varchar(50) | Non | - | - | - | - |
race_source_concept_id |
En raison du petit nombre d'options, ce champ tend à être zéro. | Si les données source codent l'origine ethnique dans un vocabulaire supporté par OMOP, stockez le concept_id ici. | integer | Non | - | FK | CONCEPT | - |
ethnicity_source_value |
Ce champ est utilisé pour stocker l'ethnicité de la personne à partir des données source. | Mettez l'ethnicité telle qu'elle apparaît dans les données source. | varchar(50) | Non | - | - | - | - |
ethnicity_source_concept_id |
En raison du petit nombre d'options, ce champ tend à être zéro. | Si les données source codent l'ethnicité dans un vocabulaire supporté par OMOP, stockez le concept_id ici. | integer | Non | - | FK | CONCEPT | - |
Description de la table
Cette table sert de gestion centrale de l'identité pour toutes les Personnes dans la base de données. Elle contient des enregistrements qui identifient de manière unique chaque personne ou patient, ainsi que quelques informations démographiques.
Guide utilisateur
Tous les enregistrements de cette table sont des Personnes indépendantes.
Conventions ETL
Toutes les Personnes d'une base de données doivent avoir un enregistrement dans cette table, sauf si elles échouent aux exigences de qualité des données spécifiées dans l'ETL. Les Personnes sans Événements doivent quand même avoir un enregistrement. Si plus d'une source de données contribue aux Événements de la base de données, les Personnes doivent être réconciliées, si possible, entre les sources pour créer un seul enregistrement par Personne. Le contenu de BIRTH_DATETIME doit être équivalent au contenu de BIRTH_DAY, BIRTH_MONTH et BIRTH_YEAR.
Pour les conventions détaillées, consultez le dépôt THEMIS.
OBSERVATION_PERIOD
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
observation_period_id |
Identifie chaque période d'observation distincte par personne. | Attribuez un ID unique à chaque période discrète par personne. | integer | Oui | PK | - | - | - |
person_id |
Lien vers la personne concernée par la période d'observation. | Doit correspondre à une entrée valide dans la table PERSON. | integer | Oui | - | FK | PERSON | - |
observation_period_start_date |
Détermine le début de la période. | Souvent déduit comme la date de l'événement le plus ancien ; dans les données d'assurance, représente le début de l'affiliation. | date | Oui | - | - | - | - |
observation_period_end_date |
Détermine la fin de la période quand tous les événements sont capturés. | Souvent déduit comme la date de l'événement le plus récent ; dans les données d'assurance, représente la fin de l'affiliation. | date | Oui | - | - | - | - |
period_type_concept_id |
Indique la source de provenance (affiliation, DPI, autre). | Sélectionnez le concept représentant la méthode de détermination ; domaine Type Concept standard. | integer | Oui | - | FK | CONCEPT | Type Concept |
Description de la table
La table OBSERVATION_PERIOD définit les périodes de temps pendant lesquelles les événements cliniques sont censés être enregistrés pour une personne. Elle établit la période où les événements indiquent des occurrences réelles, et leur absence suggère une non-occurrence.
Guide utilisateur
Chaque personne peut avoir plusieurs enregistrements OBSERVATION_PERIOD non chevauchants. Les événements peuvent exister en dehors de ces périodes mais ne peuvent pas être présumés absents. Les calculs d'incidence et de prévalence ne doivent utiliser que les périodes d'observation actives. Lors de la définition des cohortes, les événements en dehors de ces périodes peuvent informer les critères d'inclusion, bien que l'exhaustivité ne soit pas garantie. Les périodes courtes (jours uniques) peuvent fausser les calculs de taux, donc l'application d'exigences minimales de temps d'observation est recommandée.
Conventions ETL
Chaque personne nécessite au moins un OBSERVATION_PERIOD représentant les intervalles avec une capture élevée d'événements cliniques. Ceux-ci peuvent dériver des périodes d'affiliation (données d'assurance) ou nécessiter une inférence (systèmes DPI). Le début reflète typiquement l'événement clinique le plus ancien, et la fin reflète soit l'événement le plus récent, soit la date de coupure de la base de données. Les périodes à événement unique sont valides. Les périodes chevauchantes ou adjacentes doivent être fusionnées en une seule.
DEATH
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
person_id |
Identifiant unique liant à la personne décédée. | Lien vers la table PERSON. | integer | Oui | PK | FK | PERSON | - |
death_date |
Date de décès de la personne. | Si la date précise n'est pas connue, estimez la date. | date | Oui | - | - | - | - |
death_datetime |
Date et heure de décès de la personne. | Si aucune heure n'est donnée, définir à minuit (00:00:00). | datetime | Non | - | - | - | - |
death_type_concept_id |
Provenance de l'enregistrement de décès. | Utilisez ce champ pour identifier la provenance de l'enregistrement de décès (par ex. DPI, certificat de décès, données d'assurance). | integer | Oui | - | FK | CONCEPT | Type Concept |
cause_concept_id |
Concept standard représentant la cause du décès. | Mappez la cause du décès vers un Concept Standard dans le domaine Condition si disponible. | integer | Non | - | FK | CONCEPT | Condition |
cause_source_value |
Code source pour la cause du décès. | Stockez la valeur source originale. | varchar(50) | Non | - | - | - | - |
cause_source_concept_id |
Concept représentant la cause source du décès. | Si les données source codent la cause du décès dans un vocabulaire supporté par OMOP, stockez le concept_id ici. | integer | Non | - | FK | CONCEPT | - |
Description de la table
La table DEATH contient l'événement clinique du décès d'une personne. Chaque personne peut avoir au maximum un enregistrement dans cette table. La cause du décès peut être capturée si disponible.
Guide utilisateur
Les personnes vivantes ne doivent pas avoir d'enregistrement dans cette table. Chaque personne ne peut avoir qu'un seul enregistrement de décès. Si plusieurs enregistrements de décès existent dans les données source, choisissez le plus fiable en fonction de l'évaluation de la qualité des données.
Conventions ETL
Si les informations de décès proviennent de plusieurs sources (par ex. DPI et données d'assurance), réconciliez-les pour créer un seul enregistrement de décès. Le death_type_concept_id doit refléter la source la plus fiable. La cause du décès doit être mappée vers un Concept Standard dans le domaine Condition quand c'est possible.
VISIT_OCCURRENCE
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
visit_occurrence_id |
Identifiant unique pour chaque interaction. | Créé en attribuant un ID distinct à chaque rencontre patient-système de santé. | integer | Oui | PK | - | - | - |
person_id |
Identifie le patient. | Lien vers la table PERSON. | integer | Oui | - | FK | PERSON | - |
visit_concept_id |
Concept standard du domaine Visit représentant le type de rencontre. | Remplissez ce champ en fonction du type de visite effectuée. | integer | Oui | - | FK | CONCEPT | Visit |
visit_start_date |
Date d'admission pour les hospitalisations ; date d'interaction patient-prestataire pour les autres. | Si cette information n'est pas disponible, l'enregistrement doit être supprimé. | date | Oui | - | - | - | - |
visit_start_datetime |
Heure de début de la visite. | Si aucune heure n'est donnée pour la date de début d'une visite, définir à minuit (00:00:00). | datetime | Non | - | - | - | - |
visit_end_date |
Date de sortie pour les hospitalisations ; identique à la date de début pour les visites du même jour. | Les dates de fin de visite sont obligatoires. | date | Oui | - | - | - | - |
visit_end_datetime |
Heure de fin de la visite. | Défaut à minuit si non disponible. | datetime | Non | - | - | - | - |
visit_type_concept_id |
Indique la provenance (DPI vs. données d'assurance). | Remplissez ce champ en fonction de la provenance de l'enregistrement de visite. | integer | Oui | - | FK | CONCEPT | Type Concept |
provider_id |
Prestataire unique associé. | S'il y a plusieurs prestataires associés à une visite, vous devrez choisir lequel mettre ici. | integer | Non | - | FK | PROVIDER | - |
care_site_id |
Localisation de l'établissement de santé. | Lien vers la table CARE_SITE. | integer | Non | - | FK | CARE_SITE | - |
visit_source_value |
Valeur source verbatim indiquant le type de visite. | Stockez le code source original. | varchar(50) | Non | - | - | - | - |
visit_source_concept_id |
Concept de codage du système source si supporté par OMOP. | Mappez vers le concept si la source utilise un vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
admitted_from_concept_id |
Concept standard du domaine Visit indiquant l'origine de l'admission. | Si une personne a été admise depuis son domicile ou s'est auto-référée, définir à 0. | integer | Non | - | FK | CONCEPT | Visit |
admitted_from_source_value |
Valeur source verbatim pour l'origine de l'admission. | Stockez la valeur source originale. | varchar(50) | Non | - | - | - | - |
discharged_to_concept_id |
Concept de destination de sortie. | On suppose qu'une personne sort vers son domicile donc il n'y a pas de concept_id standard pour 'domicile'. Utilisez concept_id = 0. | integer | Non | - | FK | CONCEPT | Visit |
discharged_to_source_value |
Valeur source verbatim pour la destination de sortie. | Stockez la valeur source originale. | varchar(50) | Non | - | - | - | - |
preceding_visit_occurrence_id |
Lien vers la visite immédiatement précédente pour la même personne. | Utilisez pour chaîner les visites chronologiquement. | integer | Non | - | FK | VISIT_OCCURRENCE | - |
Description de la table
La table VISIT_OCCURRENCE contient des événements représentant les périodes où les personnes interagissent avec le système de santé. Ces rencontres sont configurées par des circonstances spécifiques incluant la localisation du patient (institutionnelle vs. à distance), la disponibilité du prestataire et la durée du séjour.
Guide utilisateur
Les types de visites sont organisés hiérarchiquement en utilisant des concepts standardisés du domaine Visit. Les configurations de visites courantes incluent : Visite hospitalière (admission à l'hôpital avec séjour au lit dépassant un jour), Visite aux urgences (soins d'urgence le même jour), Visite ambulatoire (soins ambulatoires le même jour sans lit), Visite à domicile (le prestataire fournit le service au domicile du patient), Visite de télésanté (interaction patient-prestataire à distance), Visites en pharmacie/laboratoire (visites spécialisées le même jour), Visite de gestion de cas (interaction administrative sans prestataires). La durée de la visite, ou 'durée de séjour', est définie comme VISIT_END_DATE - VISIT_START_DATE.
Conventions ETL
Les concepts de visite dérivent des systèmes de codage de santé (CPT, Place of Service). Lorsqu'ils ne sont pas disponibles, les visites doivent être inférées par des hypothèses ETL définies. Les visites peuvent être adjacentes mais ne peuvent pas se chevaucher sur des dates non-limites. Les visites multi-jours ne peuvent pas partager de jours sauf aux points de début/fin.
VISIT_DETAIL
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
visit_detail_id |
Identifiant unique pour chaque enregistrement de détail de visite. | Généré lors de l'ETL. | integer | Oui | PK | - | - | - |
person_id |
Identifie le patient. | Lien vers la table PERSON. | integer | Oui | - | FK | PERSON | - |
visit_detail_concept_id |
Concept standard pour le type de détail de visite. | Doit être un descendant du VISIT_CONCEPT_ID de la visite parente. | integer | Oui | - | FK | CONCEPT | Visit |
visit_detail_start_date |
Date de début du détail de visite. | Champ obligatoire. | date | Oui | - | - | - | - |
visit_detail_start_datetime |
Date et heure de début du détail de visite. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
visit_detail_end_date |
Date de fin du détail de visite. | Champ obligatoire. | date | Oui | - | - | - | - |
visit_detail_end_datetime |
Date et heure de fin du détail de visite. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
visit_detail_type_concept_id |
Provenance de l'enregistrement de détail de visite. | Indique d'où proviennent les données. | integer | Oui | - | FK | CONCEPT | Type Concept |
provider_id |
Professionnel de santé associé au détail de visite. | Lien vers la table PROVIDER. | integer | Non | - | FK | PROVIDER | - |
care_site_id |
Établissement de soins où le détail de visite a eu lieu. | Lien vers la table CARE_SITE. | integer | Non | - | FK | CARE_SITE | - |
visit_detail_source_value |
Valeur source pour le type de détail de visite. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
visit_detail_source_concept_id |
Concept source pour le type de détail de visite. | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
admitted_from_concept_id |
Concept indiquant l'origine de l'admission. | Utiliser 0 pour le domicile ou l'auto-référence. | integer | Non | - | FK | CONCEPT | Visit |
admitted_from_source_value |
Valeur source pour l'origine de l'admission. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
discharged_to_concept_id |
Concept de destination de sortie. | Utiliser 0 pour un retour à domicile. | integer | Non | - | FK | CONCEPT | Visit |
discharged_to_source_value |
Valeur source pour la destination de sortie. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
preceding_visit_detail_id |
Lien vers le détail de visite immédiatement précédent. | Utiliser pour chaîner les détails de visite chronologiquement. | integer | Non | - | FK | VISIT_DETAIL | - |
parent_visit_detail_id |
Lien vers un détail de visite parent pour les hiérarchies imbriquées. | Utiliser pour les hiérarchies de visites à plusieurs niveaux. | integer | Non | - | FK | VISIT_DETAIL | - |
visit_occurrence_id |
Lien vers la visite parente. | Lien obligatoire vers la table VISIT_OCCURRENCE. | integer | Oui | - | FK | VISIT_OCCURRENCE | - |
Description de la table
La table VISIT_DETAIL représente les détails granulaires des enregistrements VISIT_OCCURRENCE parents. Elle maintient une relation 1:n où chaque VISIT_OCCURRENCE peut avoir zéro ou plusieurs enregistrements VISIT_DETAIL associés. Les exemples incluent les transferts d'unité pendant les séjours hospitaliers ou les lignes de facturation individuelles dans les demandes de remboursement.
Guide utilisateur
Les enregistrements VISIT_DETAIL doivent avoir leur VISIT_OCCURRENCE_ID associé spécifié. Chaque VISIT_DETAIL_CONCEPT_ID doit être un descendant du VISIT_CONCEPT_ID de la visite parente, maintenant une cohérence hiérarchique au sein de la structure du domaine des visites.
Conventions ETL
Le remplissage de VISIT_DETAIL est optionnel mais recommandé lorsque les données sources nécessitent une logique d'agrégation pour créer des enregistrements VISIT_OCCURRENCE unifiés. Dans les systèmes de dossiers médicaux électroniques, plusieurs interactions avec des professionnels de santé peuvent être consolidées en une seule visite en utilisant VISIT_DETAIL pour préserver les informations granulaires des rencontres.
CONDITION_OCCURRENCE
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
condition_occurrence_id |
Identifiant unique pour chaque occurrence de condition. | Généré lors de l'ETL. | integer | Oui | PK | - | - | - |
person_id |
Identifie le patient. | Lien vers la table PERSON. | integer | Oui | - | FK | PERSON | - |
condition_concept_id |
Concept standard représentant la condition. | Mapper le code source vers un Concept Standard du domaine Condition. | integer | Oui | - | FK | CONCEPT | Condition |
condition_start_date |
Date à laquelle la condition a été diagnostiquée ou a commencé. | Champ obligatoire. | date | Oui | - | - | - | - |
condition_start_datetime |
Date et heure auxquelles la condition a été diagnostiquée ou a commencé. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
condition_end_date |
Date à laquelle la condition s'est résolue. | Souvent indisponible ; utiliser CONDITION_ERA pour les périodes dérivées. | date | Non | - | - | - | - |
condition_end_datetime |
Date et heure auxquelles la condition s'est résolue. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
condition_type_concept_id |
Provenance de l'enregistrement de condition. | Indique d'où proviennent les données (DME, remboursements, etc.). | integer | Oui | - | FK | CONCEPT | Type Concept |
condition_status_concept_id |
Statut de la condition (préliminaire, final, etc.). | Utiliser les concepts du domaine Condition Status. | integer | Non | - | FK | CONCEPT | Condition Status |
stop_reason |
Raison pour laquelle la condition n'est plus enregistrée. | Souvent indisponible. | varchar(20) | Non | - | - | - | - |
provider_id |
Professionnel de santé ayant diagnostiqué la condition. | Lien vers la table PROVIDER. | integer | Non | - | FK | PROVIDER | - |
visit_occurrence_id |
Visite au cours de laquelle la condition a été diagnostiquée. | Lien vers la table VISIT_OCCURRENCE. | integer | Non | - | FK | VISIT_OCCURRENCE | - |
visit_detail_id |
Détail de visite au cours duquel la condition a été diagnostiquée. | Lien vers la table VISIT_DETAIL. | integer | Non | - | FK | VISIT_DETAIL | - |
condition_source_value |
Code source pour la condition. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
condition_source_concept_id |
Concept source pour la condition. | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
condition_status_source_value |
Valeur source pour le statut de la condition. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
Description de la table
Cette table documente les événements cliniques indiquant une maladie ou une condition médicale. Les enregistrements capturent les diagnostics, signes ou symptômes soit observés par les professionnels de santé, soit rapportés par les patients.
Guide utilisateur
Les conditions sont organisées dans un système hiérarchique au sein du domaine Condition. Enregistrer toutes les conditions sources sans appliquer de filtres analytiques. Les diagnostics d'exclusion doivent être exclus. Les antécédents familiaux et les événements médicaux passés appartiennent à la table OBSERVATION.
Conventions ETL
Tous les codes sources mappant vers des concepts standard du domaine Condition doivent être enregistrés dans cette table. Les conditions en double au sein d'une même rencontre nécessitent une logique ETL pour déterminer s'il faut les consolider ou maintenir des enregistrements séparés.
DRUG_EXPOSURE
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
drug_exposure_id |
Identifiant unique pour chaque enregistrement d'exposition médicamenteuse. | Généré lors de l'ETL. | integer | Oui | PK | - | - | - |
person_id |
Personne recevant le médicament. | Lien vers la table PERSON. | integer | Oui | - | FK | PERSON | - |
drug_concept_id |
Concept standard du médicament (mappé depuis la source). | Doit mapper vers le domaine Drug. | integer | Oui | - | FK | CONCEPT | Drug |
drug_exposure_start_date |
Date de début de prescription, de délivrance ou d'administration. | Champ obligatoire. | date | Oui | - | - | - | - |
drug_exposure_start_datetime |
Date et heure de début de l'exposition médicamenteuse. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
drug_exposure_end_date |
Date de fin de l'exposition médicamenteuse. | Déduite de la date de début et de la durée si non disponible. | date | Oui | - | - | - | - |
drug_exposure_end_datetime |
Date et heure de fin de l'exposition médicamenteuse. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
verbatim_end_date |
Date de fin telle qu'elle apparaît dans les données sources. | Stocker la date de fin d'origine si disponible. | date | Non | - | - | - | - |
drug_type_concept_id |
Provenance (prescrit, dispensé, administré). | Domaine Type Concept. | integer | Oui | - | FK | CONCEPT | Type Concept |
stop_reason |
Raison de l'arrêt du médicament. | Souvent indisponible. | varchar(20) | Non | - | - | - | - |
refills |
Renouvellements prévus au moment de la prescription. | Stocker comme entier. | integer | Non | - | - | - | - |
quantity |
Quantité totale dispensée. | Conversion d'unité vers la table DRUG_STRENGTH requise. | float | Non | - | - | - | - |
days_supply |
Jours d'approvisionnement tels qu'enregistrés. | Exclure les valeurs négatives ou erronément élevées. | integer | Non | - | - | - | - |
sig |
Instructions verbatim du prescripteur pour le médicament. | Stocker comme texte. | text | Non | - | - | - | - |
route_concept_id |
Voie d'administration. | Domaine Route. | integer | Non | - | FK | CONCEPT | Route |
lot_number |
Identifiant du lot de fabrication. | Stocker si disponible. | varchar(50) | Non | - | - | - | - |
provider_id |
Prescripteur ou professionnel administrant. | Lien vers la table PROVIDER. | integer | Non | - | FK | PROVIDER | - |
visit_occurrence_id |
Visite associée. | Lien vers la table VISIT_OCCURRENCE. | integer | Non | - | FK | VISIT_OCCURRENCE | - |
visit_detail_id |
Détail de visite associé (ex. séjour en réanimation). | Lien vers la table VISIT_DETAIL. | integer | Non | - | FK | VISIT_DETAIL | - |
drug_source_value |
Code source (NDC, Gemscript). | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
drug_source_concept_id |
Concept source (non standard). | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
route_source_value |
Voie verbatim des données sources. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
dose_unit_source_value |
Unité de dose verbatim. | Champ déprécié. | varchar(50) | Non | - | - | - | - |
Description de la table
La table DRUG_EXPOSURE capture les enregistrements documentant l'exposition d'une personne à un médicament ou une substance biochimique introduite dans le corps. Les médicaments comprennent les médicaments sur ordonnance et en vente libre, les vaccins et les thérapies biologiques.
Guide utilisateur
Les enregistrements de cette table indiquent l'exposition aux médicaments. La table documente les prescriptions rédigées, les prescriptions dispensées et les médicaments administrés par les professionnels de santé, le DRUG_TYPE_CONCEPT_ID différenciant ces types.
Conventions ETL
Les informations sur la quantité et la dose arrivent dans des formats variés ; l'ETL doit capturer autant de détails que possible. Les enregistrements multiples le même jour pour des médicaments identiques ne doivent pas être dédupliqués sans preuve solide de vraie duplication. Une attention particulière est requise pour les renouvellements de prescription.
PROCEDURE_OCCURRENCE
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
procedure_occurrence_id |
Identifiant unique pour chaque occurrence de procédure. | Généré lors de l'ETL. | integer | Oui | PK | - | - | - |
person_id |
Identifie le patient. | Lien vers la table PERSON. | integer | Oui | - | FK | PERSON | - |
procedure_concept_id |
Concept standard représentant la procédure. | Mapper le code source vers un Concept Standard du domaine Procedure. | integer | Oui | - | FK | CONCEPT | Procedure |
procedure_date |
Date à laquelle la procédure a été réalisée. | Champ obligatoire. | date | Oui | - | - | - | - |
procedure_datetime |
Date et heure de la procédure. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
procedure_end_date |
Date de fin de la procédure. | Optionnel ; pour les procédures sur plusieurs jours. | date | Non | - | - | - | - |
procedure_end_datetime |
Date et heure de fin de la procédure. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
procedure_type_concept_id |
Provenance de l'enregistrement de procédure. | Domaine Type Concept. | integer | Oui | - | FK | CONCEPT | Type Concept |
modifier_concept_id |
Modificateur de procédure (ex. bilatéral, latéralité). | Stocker si disponible. | integer | Non | - | FK | CONCEPT | - |
quantity |
Nombre de fois que la procédure a été réalisée. | Stocker comme entier. | integer | Non | - | - | - | - |
provider_id |
Professionnel de santé ayant réalisé la procédure. | Lien vers la table PROVIDER. | integer | Non | - | FK | PROVIDER | - |
visit_occurrence_id |
Visite au cours de laquelle la procédure a été réalisée. | Lien vers la table VISIT_OCCURRENCE. | integer | Non | - | FK | VISIT_OCCURRENCE | - |
visit_detail_id |
Détail de visite au cours duquel la procédure a été réalisée. | Lien vers la table VISIT_DETAIL. | integer | Non | - | FK | VISIT_DETAIL | - |
procedure_source_value |
Code source pour la procédure. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
procedure_source_concept_id |
Concept source pour la procédure. | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
modifier_source_value |
Valeur source pour le modificateur. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
Description de la table
La table PROCEDURE_OCCURRENCE contient les enregistrements des activités ou processus prescrits par, ou réalisés par, un professionnel de santé sur le patient à des fins diagnostiques ou thérapeutiques.
Guide utilisateur
Les examens de laboratoire sont distincts des procédures. Les mesures représentent des résultats observés avec des quantités et unités attendues, tandis que les procédures sont des actions. La phlébotomie, bien que techniquement une procédure, est rarement capturée séparément car elle est généralement associée aux examens de laboratoire.
Conventions ETL
Lors du traitement des enregistrements en double, l'ETL doit déterminer s'il faut les consolider en un seul enregistrement ou les maintenir séparément. Les codes sources mappés vers des Concepts Standard du domaine Procedure doivent être enregistrés dans cette table.
DEVICE_EXPOSURE
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
device_exposure_id |
Identifiant unique pour chaque enregistrement d'exposition à un dispositif. | Généré lors de l'ETL. | integer | Oui | PK | - | - | - |
person_id |
Identifie le patient. | Lien vers la table PERSON. | integer | Oui | - | FK | PERSON | - |
device_concept_id |
Concept standard représentant le dispositif. | Mapper vers le domaine Device. | integer | Oui | - | FK | CONCEPT | Device |
device_exposure_start_date |
Date de début de l'exposition au dispositif. | Champ obligatoire. | date | Oui | - | - | - | - |
device_exposure_start_datetime |
Date et heure de début de l'exposition au dispositif. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
device_exposure_end_date |
Date de fin de l'exposition au dispositif. | Optionnel. | date | Non | - | - | - | - |
device_exposure_end_datetime |
Date et heure de fin de l'exposition au dispositif. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
device_type_concept_id |
Provenance de l'enregistrement du dispositif. | Domaine Type Concept. | integer | Oui | - | FK | CONCEPT | Type Concept |
unique_device_id |
Identifiant unique du dispositif (UDI). | Stocker si disponible. | varchar(255) | Non | - | - | - | - |
production_id |
Identifiant de production du fabricant. | Stocker si disponible. | varchar(255) | Non | - | - | - | - |
quantity |
Nombre de dispositifs utilisés. | Stocker comme entier. | integer | Non | - | - | - | - |
provider_id |
Professionnel de santé ayant posé ou utilisé le dispositif. | Lien vers la table PROVIDER. | integer | Non | - | FK | PROVIDER | - |
visit_occurrence_id |
Visite au cours de laquelle le dispositif a été utilisé. | Lien vers la table VISIT_OCCURRENCE. | integer | Non | - | FK | VISIT_OCCURRENCE | - |
visit_detail_id |
Détail de visite au cours duquel le dispositif a été utilisé. | Lien vers la table VISIT_DETAIL. | integer | Non | - | FK | VISIT_DETAIL | - |
device_source_value |
Code source pour le dispositif. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
device_source_concept_id |
Concept source pour le dispositif. | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
unit_concept_id |
Unité de mesure pour le dispositif. | Domaine Unit. | integer | Non | - | FK | CONCEPT | Unit |
unit_source_value |
Valeur source pour l'unité. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
unit_source_concept_id |
Concept source pour l'unité. | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
Description de la table
Le domaine Device capture les informations concernant l'exposition d'une personne à un objet physique étranger ou un instrument utilisé à des fins diagnostiques ou thérapeutiques. Cela inclut les objets implantables comme les pacemakers et les stents, les équipements et fournitures médicaux, les instruments utilisés dans les procédures médicales et les matériaux utilisés dans les soins cliniques.
Guide utilisateur
La distinction entre les dispositifs ou fournitures et les procédures est parfois floue, mais les premiers sont des objets physiques tandis que les secondes sont des actions, souvent pour appliquer un dispositif ou une fourniture.
Conventions ETL
Les codes sources et les champs de texte source qui mappent vers des Concepts Standard du domaine Device doivent être enregistrés dans cette table.
MEASUREMENT
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
measurement_id |
Identifiant unique pour chaque enregistrement de mesure. | Généré lors de l'ETL. | integer | Oui | PK | - | - | - |
person_id |
Identifie le patient. | Lien vers la table PERSON. | integer | Oui | - | FK | PERSON | - |
measurement_concept_id |
Concept standard représentant la mesure. | Mapper vers le domaine Measurement. | integer | Oui | - | FK | CONCEPT | Measurement |
measurement_date |
Date de la mesure. | Champ obligatoire. | date | Oui | - | - | - | - |
measurement_datetime |
Date et heure de la mesure. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
measurement_time |
Heure de la mesure (déprécié). | Utiliser measurement_datetime à la place. | varchar(10) | Non | - | - | - | - |
measurement_type_concept_id |
Provenance de l'enregistrement de mesure. | Domaine Type Concept. | integer | Oui | - | FK | CONCEPT | Type Concept |
operator_concept_id |
Opérateur pour la valeur (=, <, >, etc.). | Domaine Meas Value Operator. | integer | Non | - | FK | CONCEPT | Meas Value Operator |
value_as_number |
Résultat numérique de la mesure. | Stocker la valeur numérique. | float | Non | - | - | - | - |
value_as_concept_id |
Résultat catégoriel de la mesure. | Domaine Meas Value. | integer | Non | - | FK | CONCEPT | Meas Value |
unit_concept_id |
Unité de la mesure. | Domaine Unit. | integer | Non | - | FK | CONCEPT | Unit |
range_low |
Borne inférieure de la plage normale. | Stocker si disponible. | float | Non | - | - | - | - |
range_high |
Borne supérieure de la plage normale. | Stocker si disponible. | float | Non | - | - | - | - |
provider_id |
Professionnel de santé ayant prescrit ou réalisé la mesure. | Lien vers la table PROVIDER. | integer | Non | - | FK | PROVIDER | - |
visit_occurrence_id |
Visite au cours de laquelle la mesure a été effectuée. | Lien vers la table VISIT_OCCURRENCE. | integer | Non | - | FK | VISIT_OCCURRENCE | - |
visit_detail_id |
Détail de visite au cours duquel la mesure a été effectuée. | Lien vers la table VISIT_DETAIL. | integer | Non | - | FK | VISIT_DETAIL | - |
measurement_source_value |
Code source pour la mesure. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
measurement_source_concept_id |
Concept source pour la mesure. | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
unit_source_value |
Valeur source pour l'unité. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
unit_source_concept_id |
Concept source pour l'unité. | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
value_source_value |
Valeur source pour le résultat. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
measurement_event_id |
Lien vers un autre événement clinique. | Stocker si disponible. | integer | Non | - | - | - | - |
meas_event_field_concept_id |
Concept identifiant le type d'événement lié. | Mapper vers un concept. | integer | Non | - | FK | CONCEPT | - |
Description de la table
La table MEASUREMENT enregistre des valeurs structurées (numériques ou catégorielles) obtenues par un examen ou des tests systématiques et standardisés d'une personne ou de son échantillon. Cela inclut les examens de laboratoire, les signes vitaux et les résultats quantitatifs de pathologie.
Guide utilisateur
Les mesures sont principalement des examens de laboratoire avec quelques exceptions, comme la pression artérielle ou les tests fonctionnels. Les résultats sont donnés sous forme de combinaison valeur et unité. Lors de l'investigation des mesures, recherchez les operator_concept_ids (<, >, etc.).
Conventions ETL
Seules les valeurs sources mappant vers des concepts du domaine Measurement appartiennent à cette table. Bien que les mesures aient toujours des résultats, les champs VALUE_AS_NUMBER et VALUE_AS_CONCEPT_ID sont optionnels car les données sources manquent souvent d'informations sur les résultats.
OBSERVATION
| Champ CDM | Guide utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
observation_id |
Identifiant unique pour chaque enregistrement d'observation. | Généré lors de l'ETL. | integer | Oui | PK | - | - | - |
person_id |
Identifie le patient. | Lien vers la table PERSON. | integer | Oui | - | FK | PERSON | - |
observation_concept_id |
Concept standard représentant l'observation. | Mapper vers le domaine Observation. | integer | Oui | - | FK | CONCEPT | - |
observation_date |
Date de l'observation. | Champ obligatoire. | date | Oui | - | - | - | - |
observation_datetime |
Date et heure de l'observation. | Définir à minuit si l'heure n'est pas disponible. | datetime | Non | - | - | - | - |
observation_type_concept_id |
Provenance de l'enregistrement d'observation. | Domaine Type Concept. | integer | Oui | - | FK | CONCEPT | Type Concept |
value_as_number |
Valeur numérique de l'observation. | Stocker si applicable. | float | Non | - | - | - | - |
value_as_string |
Valeur textuelle de l'observation. | Stocker si applicable. | varchar(60) | Non | - | - | - | - |
value_as_concept_id |
Valeur catégorielle de l'observation. | Mapper vers un concept. | integer | Non | - | FK | CONCEPT | - |
qualifier_concept_id |
Qualificateur pour l'observation. | Stocker si applicable. | integer | Non | - | FK | CONCEPT | - |
unit_concept_id |
Unité de l'observation. | Domaine Unit. | integer | Non | - | FK | CONCEPT | Unit |
provider_id |
Professionnel de santé ayant effectué l'observation. | Lien vers la table PROVIDER. | integer | Non | - | FK | PROVIDER | - |
visit_occurrence_id |
Visite au cours de laquelle l'observation a été effectuée. | Lien vers la table VISIT_OCCURRENCE. | integer | Non | - | FK | VISIT_OCCURRENCE | - |
visit_detail_id |
Détail de visite au cours duquel l'observation a été effectuée. | Lien vers la table VISIT_DETAIL. | integer | Non | - | FK | VISIT_DETAIL | - |
observation_source_value |
Code source pour l'observation. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
observation_source_concept_id |
Concept source pour l'observation. | Mapper vers un concept si la source utilise le vocabulaire OMOP. | integer | Non | - | FK | CONCEPT | - |
unit_source_value |
Valeur source pour l'unité. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
qualifier_source_value |
Valeur source pour le qualificateur. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
value_source_value |
Valeur source pour le résultat. | Stocker la valeur source d'origine. | varchar(50) | Non | - | - | - | - |
observation_event_id |
Lien vers un autre événement clinique. | Stocker si disponible. | integer | Non | - | - | - | - |
obs_event_field_concept_id |
Concept identifiant le type d'événement lié. | Mapper vers un concept. | integer | Non | - | FK | CONCEPT | - |
Description de la table
La table OBSERVATION capture les faits cliniques sur une personne obtenus par examen, interrogatoire ou procédures. Elle enregistre les données qui ne peuvent pas être représentées ailleurs, comme les faits sociaux, les choix de mode de vie et les antécédents médicaux.
Guide utilisateur
Les observations diffèrent des mesures car elles ne nécessitent pas de tests standardisés pour générer des faits cliniques. La table enregistre généralement quand les observations ont été obtenues. Les exemples incluent les antécédents médicaux, les antécédents familiaux, les besoins de traitement, les circonstances sociales et les schémas d'utilisation des soins de santé.
Conventions ETL
Les enregistrements mappant vers des domaines autres que Condition, Procedure, Drug, Specimen, Measurement ou Device appartiennent ici. Les observations fonctionnent comme des paires attribut-valeur avec le Concept d'Observation comme attribut et les faits cliniques comme valeurs. Les valeurs peuvent être des Concepts, numériques ou textuelles.
NOTE
Description de la table
La table NOTE capture les notes cliniques et de texte libre documentant les soins du patient. Ces notes sont écrites par les professionnels de santé et contiennent des informations narratives sur les visites, les diagnostics, les traitements et les observations qui ne peuvent pas être facilement structurées.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
note_id | Identifiant unique de la note. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
person_id | Référence au patient associé à la note. | Lien vers PERSON.person_id. | INTEGER | Oui | FK | PERSON | ||
note_date | Date à laquelle la note a été écrite. | Date de création de la note. | DATE | Oui | ||||
note_datetime | Date et heure de la note. | Si non disponible, dérivé de note_date. | DATETIME | Non | ||||
note_type_concept_id | Type de note (provenance des données). | Concept du vocabulaire Note Type. | INTEGER | Oui | FK | CONCEPT | Type Concept | |
note_class_concept_id | Catégorie de la note (ex: note de sortie, compte-rendu opératoire). | Concepts du domaine Note Class. | INTEGER | Oui | FK | CONCEPT | ||
note_title | Titre optionnel de la note. | Texte libre pour le titre. | VARCHAR(250) | Non | ||||
note_text | Contenu texte de la note. | Texte libre avec le contenu complet de la note. | TEXT | Oui | ||||
encoding_concept_id | Encodage du texte (ex: UTF-8). | Concept représentant l'encodage caractère. | INTEGER | Oui | FK | CONCEPT | ||
language_concept_id | Langue de la note. | Concept du vocabulaire Language. | INTEGER | Oui | FK | CONCEPT | ||
provider_id | Professionnel ayant rédigé la note. | Lien vers PROVIDER.provider_id. | INTEGER | Non | FK | PROVIDER | ||
visit_occurrence_id | Visite associée à la note. | Lien vers VISIT_OCCURRENCE.visit_occurrence_id. | INTEGER | Non | FK | VISIT_OCCURRENCE | ||
visit_detail_id | Détail de visite associé à la note. | Lien vers VISIT_DETAIL.visit_detail_id. | INTEGER | Non | FK | VISIT_DETAIL | ||
note_source_value | Valeur source pour le type de note. | Code ou texte original du système source. | VARCHAR(50) | Non | ||||
note_event_id | ID de l'événement clinique lié à la note. | Référence polymorphe vers un événement clinique. | BIGINT | Non | ||||
note_event_field_concept_id | Concept identifiant la table de l'événement. | Permet d'identifier la table source de note_event_id. | INTEGER | Non | FK | CONCEPT |
Guide Utilisateur
La table NOTE contient les enregistrements de texte libre générés lors des interactions cliniques. Elle est essentielle pour capturer les informations narratives qui ne peuvent pas être codées dans les tables structurées. Les notes peuvent être analysées par des outils de NLP pour extraire des concepts (voir NOTE_NLP).
Conventions ETL
Le champ note_class_concept_id permet de catégoriser les notes (lettre de sortie, compte-rendu d'imagerie, etc.). L'encodage et la langue doivent être spécifiés pour permettre le traitement NLP ultérieur. Les champs note_event_id et note_event_field_concept_id permettent de lier la note à un événement clinique spécifique.
NOTE_NLP
Description de la table
La table NOTE_NLP stocke les résultats de l'analyse NLP (Natural Language Processing) appliquée aux notes cliniques. Elle capture les termes et concepts médicaux extraits automatiquement du texte libre, permettant de transformer les données non structurées en informations codifiées exploitables.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
note_nlp_id | Identifiant unique de l'extraction NLP. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
note_id | Référence à la note source analysée. | Lien vers NOTE.note_id. | INTEGER | Oui | FK | NOTE | ||
section_concept_id | Section de la note où le terme a été trouvé. | Concept identifiant la section (ex: antécédents, traitement). | INTEGER | Non | FK | CONCEPT | ||
snippet | Fragment de texte contenant le terme extrait. | Contexte textuel autour du terme identifié. | VARCHAR(250) | Non | ||||
offset | Position du début du terme dans la note. | Index de caractère du début de l'extraction. | VARCHAR(50) | Non | ||||
lexical_variant | Forme exacte du terme trouvé dans le texte. | Texte tel qu'il apparaît dans la note source. | VARCHAR(250) | Oui | ||||
note_nlp_concept_id | Concept standard mappé au terme extrait. | Concept OMOP correspondant au terme NLP. | INTEGER | Non | FK | CONCEPT | ||
note_nlp_source_concept_id | Concept source du terme avant mapping. | Concept non-standard du vocabulaire source NLP. | INTEGER | Non | FK | CONCEPT | ||
nlp_system | Nom du système NLP utilisé. | Identifiant de l'outil NLP (ex: cTAKES, MetaMap). | VARCHAR(250) | Non | ||||
nlp_date | Date d'exécution de l'analyse NLP. | Date à laquelle le NLP a été appliqué. | DATE | Oui | ||||
nlp_datetime | Date et heure de l'analyse NLP. | Horodatage complet de l'extraction. | DATETIME | Non | ||||
term_exists | Indicateur si le terme est présent ou absent. | Y pour présent, N pour absence explicite. | VARCHAR(1) | Non | ||||
term_temporal | Contexte temporel du terme (passé, présent, futur). | Indique si le terme réfère à un état actuel ou historique. | VARCHAR(50) | Non | ||||
term_modifiers | Modificateurs contextuels du terme. | Informations sur la négation, l'incertitude, etc. | VARCHAR(2000) | Non |
Guide Utilisateur
NOTE_NLP stocke les résultats des pipelines de traitement automatique du langage naturel. Chaque enregistrement représente un concept médical extrait d'une note clinique, avec son contexte (snippet), sa position dans le texte, et le mapping vers les vocabulaires standards OMOP.
Conventions ETL
Les champs term_exists et term_temporal sont essentiels pour l'interprétation : un terme peut être mentionné comme absent ("pas de diabète") ou historique ("antécédent de pneumonie"). Le nlp_system doit documenter l'outil utilisé pour permettre la reproductibilité et l'évaluation de la qualité des extractions.
EPISODE
Description de la table
La table EPISODE représente des séquences d'événements cliniques liés à un même contexte médical, typiquement un épisode de soins pour une condition spécifique comme un cancer ou une grossesse. Elle permet de regrouper les événements associés à une maladie ou un traitement particulier.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
episode_id | Identifiant unique de l'épisode. | Clé primaire générée automatiquement. | BIGINT | Oui | PK | |||
person_id | Référence au patient concerné. | Lien vers PERSON.person_id. | BIGINT | Oui | FK | PERSON | ||
episode_concept_id | Concept définissant le type d'épisode. | Concept du domaine Episode (ex: Treatment Episode, Disease Episode). | INTEGER | Oui | FK | CONCEPT | Episode | |
episode_start_date | Date de début de l'épisode. | Premier événement de l'épisode. | DATE | Oui | ||||
episode_start_datetime | Date et heure de début. | Si non disponible, dérivé de episode_start_date. | DATETIME | Non | ||||
episode_end_date | Date de fin de l'épisode. | Dernier événement ou résolution de l'épisode. | DATE | Non | ||||
episode_end_datetime | Date et heure de fin. | Si non disponible, dérivé de episode_end_date. | DATETIME | Non | ||||
episode_parent_id | Référence à un épisode parent. | Permet de créer des hiérarchies d'épisodes. | BIGINT | Non | FK | EPISODE | ||
episode_number | Numéro séquentiel de l'épisode. | Pour numéroter les épisodes récurrents (ex: 2ème ligne de chimiothérapie). | INTEGER | Non | ||||
episode_object_concept_id | Concept décrivant l'objet de l'épisode. | Le diagnostic ou traitement concerné (ex: cancer du sein). | INTEGER | Oui | FK | CONCEPT | ||
episode_type_concept_id | Type de provenance des données. | Concept indiquant la source de l'épisode. | INTEGER | Oui | FK | CONCEPT | Type Concept | |
episode_source_value | Valeur source de l'épisode. | Code ou identifiant du système source. | VARCHAR(50) | Non | ||||
episode_source_concept_id | Concept source de l'épisode. | Concept non-standard avant mapping. | INTEGER | Non | FK | CONCEPT |
Guide Utilisateur
EPISODE est particulièrement utile pour l'oncologie où l'on suit des épisodes de maladie et de traitement. Un patient peut avoir plusieurs épisodes pour différents cancers ou différentes lignes de traitement. Les épisodes peuvent être hiérarchisés via episode_parent_id.
Conventions ETL
episode_concept_id définit la nature de l'épisode (Disease Episode pour une maladie, Treatment Episode pour un traitement). episode_object_concept_id spécifie de quoi il s'agit (ex: le type de cancer). Les événements individuels sont liés via la table EPISODE_EVENT.
EPISODE_EVENT
Description de la table
La table EPISODE_EVENT lie les épisodes aux événements cliniques individuels qui les composent. Elle permet d'associer des diagnostics, procédures, médicaments et autres événements cliniques à un épisode de soins spécifique.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
episode_id | Référence à l'épisode. | Lien vers EPISODE.episode_id. | BIGINT | Oui | FK | EPISODE | ||
event_id | ID de l'événement clinique associé. | Référence polymorphe vers l'événement (condition, drug_exposure, etc.). | BIGINT | Oui | ||||
episode_event_field_concept_id | Concept identifiant la table source de l'événement. | Permet de savoir quelle table contient l'événement référencé. | INTEGER | Oui | FK | CONCEPT |
Guide Utilisateur
EPISODE_EVENT est une table de liaison qui associe les événements cliniques (conditions, procédures, médicaments) à leurs épisodes respectifs. Par exemple, pour un épisode de cancer, on peut lier le diagnostic initial, les différentes chimiothérapies, et les bilans de surveillance.
Conventions ETL
Le champ episode_event_field_concept_id indique de quelle table provient event_id. Les concepts utilisés correspondent aux identifiants de champs CDM (ex: concept pour condition_occurrence_id, drug_exposure_id, etc.). Un même événement peut être associé à plusieurs épisodes si cliniquement pertinent.
SPECIMEN
Description de la table
La table SPECIMEN contient les informations sur les prélèvements biologiques collectés chez les patients. Elle documente les échantillons tels que le sang, l'urine, les biopsies tissulaires et autres spécimens utilisés pour les analyses de laboratoire ou les examens anatomopathologiques.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
specimen_id | Identifiant unique du prélèvement. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
person_id | Référence au patient prélevé. | Lien vers PERSON.person_id. | INTEGER | Oui | FK | PERSON | ||
specimen_concept_id | Type de prélèvement (sang, urine, biopsie, etc.). | Concept du domaine Specimen. | INTEGER | Oui | FK | CONCEPT | Specimen | |
specimen_type_concept_id | Provenance des données du spécimen. | Concept indiquant la source de l'information. | INTEGER | Oui | FK | CONCEPT | Type Concept | |
specimen_date | Date du prélèvement. | Date à laquelle l'échantillon a été collecté. | DATE | Oui | ||||
specimen_datetime | Date et heure du prélèvement. | Si non disponible, dérivé de specimen_date. | DATETIME | Non | ||||
quantity | Quantité de spécimen prélevé. | Volume ou masse selon l'unité. | FLOAT | Non | ||||
unit_concept_id | Unité de mesure de la quantité. | Concept d'unité (mL, g, etc.). | INTEGER | Non | FK | CONCEPT | Unit | |
anatomic_site_concept_id | Site anatomique du prélèvement. | Localisation du prélèvement sur le corps. | INTEGER | Non | FK | CONCEPT | Spec Anatomic Site | |
disease_status_concept_id | Statut pathologique du spécimen. | État du tissu (normal, tumoral, etc.). | INTEGER | Non | FK | CONCEPT | ||
specimen_source_id | Identifiant source du spécimen. | Numéro de tube ou d'échantillon du laboratoire. | VARCHAR(50) | Non | ||||
specimen_source_value | Valeur source du type de spécimen. | Code ou texte original du système source. | VARCHAR(50) | Non | ||||
unit_source_value | Valeur source de l'unité. | Texte de l'unité dans le système source. | VARCHAR(50) | Non | ||||
anatomic_site_source_value | Valeur source du site anatomique. | Texte de localisation du système source. | VARCHAR(50) | Non | ||||
disease_status_source_value | Valeur source du statut pathologique. | Texte original du statut dans le système source. | VARCHAR(50) | Non |
Guide Utilisateur
SPECIMEN documente les prélèvements biologiques indépendamment des analyses effectuées. Les résultats d'analyses sur ces spécimens sont dans MEASUREMENT. Cette table est particulièrement importante pour les biobanques et la recherche où la traçabilité des échantillons est essentielle.
Conventions ETL
Un même spécimen physique peut générer plusieurs enregistrements MEASUREMENT si plusieurs analyses sont effectuées. Le champ anatomic_site_concept_id utilise les concepts SNOMED pour la localisation. Le disease_status_concept_id est utile en oncologie pour distinguer les tissus sains des tissus tumoraux.
FACT_RELATIONSHIP
Description de la table
La table FACT_RELATIONSHIP permet de créer des relations entre les enregistrements de différentes tables cliniques. Elle établit des liens sémantiques entre les faits, comme la relation entre un diagnostic et un médicament prescrit pour ce diagnostic, ou entre une mesure et sa procédure associée.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
domain_concept_id_1 | Domaine du premier fait. | Concept identifiant le domaine (Condition, Drug, etc.). | INTEGER | Oui | FK | CONCEPT | Metadata | |
fact_id_1 | ID du premier fait dans sa table d'origine. | Référence vers l'enregistrement de domain_concept_id_1. | INTEGER | Oui | ||||
domain_concept_id_2 | Domaine du second fait. | Concept identifiant le domaine du second fait. | INTEGER | Oui | FK | CONCEPT | Metadata | |
fact_id_2 | ID du second fait dans sa table d'origine. | Référence vers l'enregistrement de domain_concept_id_2. | INTEGER | Oui | ||||
relationship_concept_id | Type de relation entre les deux faits. | Concept décrivant la nature de la relation. | INTEGER | Oui | FK | CONCEPT | Relationship |
Guide Utilisateur
FACT_RELATIONSHIP permet d'exprimer des relations complexes entre événements cliniques. Par exemple : "ce médicament a été prescrit pour cette condition", "cette mesure a été effectuée lors de cette procédure", ou "ces deux observations sont liées". Les relations peuvent être bidirectionnelles.
Conventions ETL
Les domain_concept_id utilisent les concepts de domaine (Drug, Condition, Measurement, etc.). Pour les relations symétriques, il faut créer deux enregistrements (A vers B et B vers A). Les relationship_concept_id définissent la sémantique de la relation (ex: "Has associated procedure", "Caused by").
LOCATION
Description de la table
La table LOCATION contient les adresses géographiques et informations de localisation. Elle peut représenter des adresses de patients, de prestataires de soins ou d'établissements de santé. Les données sont généralisées pour protéger la vie privée des patients.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
location_id | Identifiant unique de la localisation. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
address_1 | Première ligne d'adresse. | Numéro et nom de rue. | VARCHAR(50) | Non | ||||
address_2 | Deuxième ligne d'adresse. | Complément d'adresse (appartement, bâtiment, etc.). | VARCHAR(50) | Non | ||||
city | Ville. | Nom de la ville. | VARCHAR(50) | Non | ||||
state | État, région ou département. | Code ou nom de la subdivision administrative. | VARCHAR(2) | Non | ||||
zip | Code postal. | Code postal de l'adresse. | VARCHAR(9) | Non | ||||
county | Comté ou canton. | Subdivision administrative locale. | VARCHAR(20) | Non | ||||
location_source_value | Valeur source de la localisation. | Représentation originale dans le système source. | VARCHAR(50) | Non | ||||
country_concept_id | Concept du pays. | Concept géographique pour le pays. | INTEGER | Non | FK | CONCEPT | Geography | |
country_source_value | Valeur source du pays. | Nom ou code du pays dans le système source. | VARCHAR(80) | Non | ||||
latitude | Latitude géographique. | Coordonnée latitude (décimal). | FLOAT | Non | ||||
longitude | Longitude géographique. | Coordonnée longitude (décimal). | FLOAT | Non |
Guide Utilisateur
LOCATION stocke les adresses de manière générique, utilisables pour les patients (via PERSON.location_id), les prestataires (via PROVIDER) et les établissements (via CARE_SITE). Les coordonnées géographiques peuvent être utilisées pour des analyses spatiales.
Conventions ETL
Pour la protection de la vie privée, les adresses des patients doivent être généralisées (ex: code postal uniquement, pas d'adresse complète). Les coordonnées latitude/longitude peuvent être décalées ou arrondies. Les localisations des établissements peuvent être plus précises.
CARE_SITE
Description de la table
La table CARE_SITE identifie les lieux physiques où les soins sont dispensés. Cela inclut les hôpitaux, cliniques, cabinets médicaux, services hospitaliers, et autres établissements ou unités de soins où les patients reçoivent des traitements.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
care_site_id | Identifiant unique du site de soins. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
care_site_name | Nom du site de soins. | Nom de l'établissement ou du service. | VARCHAR(255) | Non | ||||
place_of_service_concept_id | Type d'établissement. | Concept décrivant le type de lieu (hôpital, clinique, etc.). | INTEGER | Non | FK | CONCEPT | Place of Service | |
location_id | Référence à l'adresse du site. | Lien vers LOCATION.location_id. | INTEGER | Non | FK | LOCATION | ||
care_site_source_value | Valeur source du site de soins. | Identifiant ou code dans le système source. | VARCHAR(50) | Non | ||||
place_of_service_source_value | Valeur source du type d'établissement. | Code original du type de lieu dans le système source. | VARCHAR(50) | Non |
Guide Utilisateur
CARE_SITE représente la hiérarchie des établissements de soins. Un hôpital peut avoir plusieurs sites de soins (urgences, réanimation, cardiologie). Les visites et événements cliniques peuvent être rattachés à un care_site pour analyser les variations de pratique entre établissements.
Conventions ETL
La granularité du care_site dépend des données sources et des besoins analytiques. On peut représenter l'hôpital entier ou descendre au niveau du service. Le place_of_service_concept_id utilise les concepts CMS Place of Service ou équivalents européens.
PROVIDER
Description de la table
La table PROVIDER contient les informations sur les professionnels de santé qui dispensent les soins. Cela inclut les médecins, infirmiers, pharmaciens et autres praticiens impliqués dans la prise en charge des patients.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
provider_id | Identifiant unique du prestataire. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
provider_name | Nom du prestataire. | Nom complet ou pseudonyme. | VARCHAR(255) | Non | ||||
npi | National Provider Identifier (USA). | Identifiant national du professionnel. | VARCHAR(20) | Non | ||||
dea | Drug Enforcement Administration ID (USA). | Identifiant pour la prescription de substances contrôlées. | VARCHAR(20) | Non | ||||
specialty_concept_id | Spécialité médicale. | Concept décrivant la spécialité (cardiologie, chirurgie, etc.). | INTEGER | Non | FK | CONCEPT | Provider | |
care_site_id | Site de soins principal du prestataire. | Lien vers CARE_SITE.care_site_id. | INTEGER | Non | FK | CARE_SITE | ||
year_of_birth | Année de naissance du prestataire. | Utilisé pour l'analyse démographique des praticiens. | INTEGER | Non | ||||
gender_concept_id | Genre du prestataire. | Concept de genre (masculin, féminin, etc.). | INTEGER | Non | FK | CONCEPT | Gender | |
provider_source_value | Valeur source du prestataire. | Identifiant dans le système source. | VARCHAR(50) | Non | ||||
specialty_source_value | Valeur source de la spécialité. | Code ou texte de spécialité du système source. | VARCHAR(50) | Non | ||||
specialty_source_concept_id | Concept source de la spécialité. | Concept non-standard de la spécialité. | INTEGER | Non | FK | CONCEPT | ||
gender_source_value | Valeur source du genre. | Code de genre du système source. | VARCHAR(50) | Non | ||||
gender_source_concept_id | Concept source du genre. | Concept non-standard du genre. | INTEGER | Non | FK | CONCEPT |
Guide Utilisateur
PROVIDER permet d'analyser les patterns de prescription et de soins par professionnel ou spécialité. Les événements cliniques peuvent référencer le provider_id pour identifier qui a réalisé l'acte ou prescrit le traitement. La spécialité est importante pour les études de variation des pratiques.
Conventions ETL
Le NPI et DEA sont des identifiants américains ; utiliser les identifiants nationaux équivalents pour d'autres pays (RPPS en France par exemple). Le provider_name peut être pseudonymisé pour la protection des données. Un même prestataire peut intervenir dans plusieurs care_sites.
COST
Description de la table
La table COST capture les informations de coûts associés aux événements cliniques. Elle permet de stocker les coûts des médicaments, procédures, visites et autres services de santé pour les analyses médico-économiques.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
cost_id | Identifiant unique du coût. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
cost_event_id | ID de l'événement associé au coût. | Référence polymorphe vers l'événement (drug_exposure_id, procedure_id, etc.). | INTEGER | Oui | ||||
cost_domain_id | Domaine de l'événement associé. | Nom du domaine (Drug, Procedure, Visit, etc.). | VARCHAR(20) | Oui | ||||
cost_type_concept_id | Type de coût. | Concept indiquant la nature du coût (facturé, remboursé, etc.). | INTEGER | Oui | FK | CONCEPT | Type Concept | |
currency_concept_id | Devise du coût. | Concept de devise (EUR, USD, etc.). | INTEGER | Non | FK | CONCEPT | Currency | |
total_charge | Montant total facturé. | Coût brut avant remboursement. | FLOAT | Non | ||||
total_cost | Coût total réel. | Coût effectif pour l'établissement. | FLOAT | Non | ||||
total_paid | Montant total payé. | Somme des paiements (assurance + patient). | FLOAT | Non | ||||
paid_by_payer | Montant payé par l'assurance. | Part remboursée par l'organisme payeur. | FLOAT | Non | ||||
paid_by_patient | Montant payé par le patient. | Reste à charge pour le patient. | FLOAT | Non | ||||
paid_patient_copay | Copaiement du patient. | Ticket modérateur ou forfait. | FLOAT | Non | ||||
paid_patient_coinsurance | Co-assurance du patient. | Pourcentage à la charge du patient. | FLOAT | Non | ||||
paid_patient_deductible | Franchise du patient. | Montant de la franchise appliquée. | FLOAT | Non | ||||
paid_by_primary | Payé par l'assurance primaire. | Remboursement de l'assurance principale. | FLOAT | Non | ||||
paid_ingredient_cost | Coût des ingrédients. | Pour les médicaments, coût des principes actifs. | FLOAT | Non | ||||
paid_dispensing_fee | Frais de dispensation. | Honoraires de dispensation pharmaceutique. | FLOAT | Non | ||||
payer_plan_period_id | Période de couverture associée. | Lien vers PAYER_PLAN_PERIOD.payer_plan_period_id. | INTEGER | Non | FK | PAYER_PLAN_PERIOD | ||
amount_allowed | Montant autorisé. | Montant maximum accepté par l'assurance. | FLOAT | Non | ||||
revenue_code_concept_id | Code de recette. | Concept du code de facturation. | INTEGER | Non | FK | CONCEPT | Revenue Code | |
revenue_code_source_value | Code de recette source. | Code original du système de facturation. | VARCHAR(50) | Non | ||||
drg_concept_id | DRG (Diagnosis Related Group). | Concept du groupe homogène de malades. | INTEGER | Non | FK | CONCEPT | DRG | |
drg_source_value | DRG source. | Code GHM/GHS original (France) ou DRG (USA). | VARCHAR(3) | Non |
Guide Utilisateur
COST permet les analyses de coût-efficacité et les études médico-économiques. Chaque coût est lié à un événement clinique spécifique via cost_event_id et cost_domain_id. Les différents champs permettent de distinguer les différentes composantes du financement des soins.
Conventions ETL
Les montants sont en unité monétaire définie par currency_concept_id. Pour la France, utiliser les codes GHM/GHS pour drg_source_value. Les champs de paiement détaillés dépendent de la structure du système de santé local. Tous les montants sont optionnels selon les données disponibles.
PAYER_PLAN_PERIOD
Description de la table
La table PAYER_PLAN_PERIOD capture les périodes de couverture d'assurance santé des patients. Elle documente les différents régimes d'assurance et les dates pendant lesquelles le patient était couvert par chaque plan.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
payer_plan_period_id | Identifiant unique de la période. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
person_id | Référence au patient. | Lien vers PERSON.person_id. | INTEGER | Oui | FK | PERSON | ||
payer_plan_period_start_date | Date de début de la couverture. | Premier jour de la période de couverture. | DATE | Oui | ||||
payer_plan_period_end_date | Date de fin de la couverture. | Dernier jour de la période de couverture. | DATE | Oui | ||||
payer_concept_id | Concept de l'organisme payeur. | Concept identifiant le type d'assureur. | INTEGER | Non | FK | CONCEPT | Payer | |
payer_source_value | Valeur source de l'organisme payeur. | Code ou nom de l'assureur dans le système source. | VARCHAR(50) | Non | ||||
payer_source_concept_id | Concept source du payeur. | Concept non-standard de l'assureur. | INTEGER | Non | FK | CONCEPT | ||
plan_concept_id | Concept du type de plan. | Concept identifiant le type de couverture. | INTEGER | Non | FK | CONCEPT | Plan | |
plan_source_value | Valeur source du plan. | Code ou nom du plan dans le système source. | VARCHAR(50) | Non | ||||
plan_source_concept_id | Concept source du plan. | Concept non-standard du plan. | INTEGER | Non | FK | CONCEPT | ||
sponsor_concept_id | Concept du sponsor. | Employeur ou organisme finançant la couverture. | INTEGER | Non | FK | CONCEPT | Sponsor | |
sponsor_source_value | Valeur source du sponsor. | Nom ou code du sponsor dans le système source. | VARCHAR(50) | Non | ||||
sponsor_source_concept_id | Concept source du sponsor. | Concept non-standard du sponsor. | INTEGER | Non | FK | CONCEPT | ||
family_source_value | Identifiant familial. | Numéro de contrat familial ou groupe. | VARCHAR(50) | Non | ||||
stop_reason_concept_id | Raison de fin de couverture. | Concept expliquant pourquoi la couverture a pris fin. | INTEGER | Non | FK | CONCEPT | ||
stop_reason_source_value | Valeur source de la raison de fin. | Code ou texte de fin dans le système source. | VARCHAR(50) | Non | ||||
stop_reason_source_concept_id | Concept source de la raison de fin. | Concept non-standard de la raison de fin. | INTEGER | Non | FK | CONCEPT |
Guide Utilisateur
PAYER_PLAN_PERIOD permet de suivre l'historique de couverture d'assurance des patients. Un patient peut avoir plusieurs périodes consécutives ou simultanées (assurance primaire et complémentaire). Cette information est cruciale pour les analyses d'accès aux soins et de suivi de population.
Conventions ETL
En France, distinguer l'assurance maladie obligatoire (AMO) des complémentaires (AMC). Créer des périodes séparées pour chaque changement de couverture. Les périodes ne doivent pas se chevaucher pour un même type de couverture. Les dates doivent être précises au jour près.
CONCEPT
Description de la table
La table CONCEPT est le cœur du système de vocabulaires OMOP. Elle contient tous les concepts standardisés utilisés pour représenter les données cliniques. Chaque concept a un identifiant unique et appartient à un vocabulaire et un domaine spécifiques.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
concept_id | Identifiant unique du concept. | Clé primaire, attribuée par OHDSI. | INTEGER | Oui | PK | |||
concept_name | Nom descriptif du concept. | Libellé lisible du concept. | VARCHAR(255) | Oui | ||||
domain_id | Domaine du concept. | Domaine auquel appartient le concept (Condition, Drug, etc.). | VARCHAR(20) | Oui | FK | DOMAIN | ||
vocabulary_id | Vocabulaire source du concept. | Identifiant du vocabulaire (SNOMED, RxNorm, LOINC, etc.). | VARCHAR(20) | Oui | FK | VOCABULARY | ||
concept_class_id | Classe du concept. | Classification au sein du vocabulaire (Clinical Finding, Ingredient, etc.). | VARCHAR(20) | Oui | FK | CONCEPT_CLASS | ||
standard_concept | Indicateur de concept standard. | S = Standard, C = Classification, NULL = Non-standard. | VARCHAR(1) | Non | ||||
concept_code | Code original du concept. | Code dans le vocabulaire source (ex: code CIM-10, code SNOMED). | VARCHAR(50) | Oui | ||||
valid_start_date | Date de début de validité. | Date à partir de laquelle le concept est utilisable. | DATE | Oui | ||||
valid_end_date | Date de fin de validité. | Date jusqu'à laquelle le concept est valide. | DATE | Oui | ||||
invalid_reason | Raison d'invalidation. | U = Upgraded, D = Deleted, NULL = Valide. | VARCHAR(1) | Non |
Guide Utilisateur
CONCEPT est la table de référence pour tous les codes utilisés dans le CDM. Les concepts standards (standard_concept = 'S') sont ceux vers lesquels toutes les données doivent être mappées. Les concepts non-standards servent de source pour le mapping. Utiliser CONCEPT_RELATIONSHIP pour trouver les mappings.
Conventions ETL
Cette table est fournie par OHDSI et ne doit pas être modifiée. Lors de l'ETL, mapper les codes sources vers les concept_id standards. Toujours vérifier que le concept est valide (valid_end_date dans le futur, invalid_reason NULL) avant de l'utiliser.
VOCABULARY
Description de la table
La table VOCABULARY liste tous les vocabulaires médicaux disponibles dans le CDM OMOP. Elle contient les métadonnées des terminologies comme SNOMED CT, ICD-10, LOINC, RxNorm, et les vocabulaires personnalisés.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
vocabulary_id | Identifiant unique du vocabulaire. | Code court du vocabulaire (ex: SNOMED, ICD10CM). | VARCHAR(20) | Oui | PK | |||
vocabulary_name | Nom complet du vocabulaire. | Nom descriptif de la terminologie. | VARCHAR(255) | Oui | ||||
vocabulary_reference | Référence externe. | URL ou citation de la source officielle. | VARCHAR(255) | Non | ||||
vocabulary_version | Version du vocabulaire. | Numéro ou date de version utilisée. | VARCHAR(255) | Non | ||||
vocabulary_concept_id | Concept représentant le vocabulaire. | Lien vers CONCEPT.concept_id pour ce vocabulaire. | INTEGER | Oui | FK | CONCEPT |
Guide Utilisateur
VOCABULARY permet de connaître les terminologies disponibles et leurs versions. Les vocabulaires les plus utilisés sont : SNOMED (conditions, procédures), RxNorm/RxNorm Extension (médicaments), LOINC (mesures de laboratoire), ICD10CM/ICD10 (classifications diagnostiques).
Conventions ETL
Cette table est fournie par OHDSI via Athena. La version du vocabulaire est importante pour la reproductibilité des analyses. Les vocabulaires personnalisés peuvent être ajoutés avec un vocabulary_id commençant par un numéro élevé (>2000000000).
DOMAIN
Description de la table
La table DOMAIN définit les domaines sémantiques du CDM OMOP. Chaque domaine correspond à une catégorie de données cliniques et détermine dans quelle table les concepts doivent être stockés.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
domain_id | Identifiant unique du domaine. | Code du domaine (ex: Condition, Drug, Measurement). | VARCHAR(20) | Oui | PK | |||
domain_name | Nom du domaine. | Nom descriptif du domaine. | VARCHAR(255) | Oui | ||||
domain_concept_id | Concept représentant le domaine. | Lien vers CONCEPT.concept_id. | INTEGER | Oui | FK | CONCEPT |
Guide Utilisateur
Les principaux domaines sont : Condition (diagnostics), Drug (médicaments), Procedure (actes), Measurement (mesures/analyses), Observation (observations), Device (dispositifs), Specimen (prélèvements). Le domaine d'un concept détermine la table de destination lors de l'ETL.
Conventions ETL
Cette table est fournie par OHDSI. Lors de l'ETL, vérifier le domain_id du concept pour savoir dans quelle table insérer l'enregistrement. Un même code source peut mapper vers des concepts de domaines différents selon le contexte.
CONCEPT_CLASS
Description de la table
La table CONCEPT_CLASS définit les classes de concepts au sein des vocabulaires. Elle permet de catégoriser les concepts selon leur niveau de granularité ou leur type au sein d'un vocabulaire donné.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
concept_class_id | Identifiant de la classe. | Code de la classe (ex: Clinical Finding, Ingredient). | VARCHAR(20) | Oui | PK | |||
concept_class_name | Nom de la classe. | Nom descriptif de la classe de concept. | VARCHAR(255) | Oui | ||||
concept_class_concept_id | Concept représentant la classe. | Lien vers CONCEPT.concept_id. | INTEGER | Oui | FK | CONCEPT |
Guide Utilisateur
Les classes varient selon le vocabulaire. Pour SNOMED : Clinical Finding, Procedure, etc. Pour RxNorm : Ingredient, Clinical Drug, Branded Drug, etc. Pour LOINC : Lab Test, Clinical Observation, etc. La classe aide à filtrer les concepts lors des recherches.
Conventions ETL
Table fournie par OHDSI. Utile pour comprendre la hiérarchie des concepts dans un vocabulaire. Par exemple, dans RxNorm, les Ingredients sont les principes actifs, les Clinical Drugs combinent ingrédient + dosage + forme.
CONCEPT_SYNONYM
Description de la table
La table CONCEPT_SYNONYM stocke les noms alternatifs et synonymes pour les concepts. Elle permet de rechercher des concepts en utilisant différentes dénominations dans plusieurs langues.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
concept_id | Concept concerné. | Lien vers CONCEPT.concept_id. | INTEGER | Oui | FK | CONCEPT | ||
concept_synonym_name | Synonyme du concept. | Nom alternatif ou traduction du concept. | VARCHAR(1000) | Oui | ||||
language_concept_id | Langue du synonyme. | Concept identifiant la langue du synonyme. | INTEGER | Oui | FK | CONCEPT | Language |
Guide Utilisateur
CONCEPT_SYNONYM est utile pour la recherche de concepts en texte libre. Un concept peut avoir plusieurs synonymes, y compris dans différentes langues. Par exemple, "Myocardial infarction" peut avoir comme synonymes "Heart attack", "MI", "Infarctus du myocarde".
Conventions ETL
Table fournie par OHDSI. Peut être enrichie avec des traductions locales. Le language_concept_id utilise les concepts de langue ISO (ex: 4180186 pour l'anglais, 4182503 pour le français). Utile pour construire des interfaces de recherche multilingues.
CONCEPT_RELATIONSHIP
Description de la table
La table CONCEPT_RELATIONSHIP définit les relations entre concepts. Elle est essentielle pour le mapping des codes sources vers les concepts standards et pour naviguer dans les hiérarchies de vocabulaires.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
concept_id_1 | Premier concept de la relation. | Concept source de la relation. | INTEGER | Oui | FK | CONCEPT | ||
concept_id_2 | Second concept de la relation. | Concept cible de la relation. | INTEGER | Oui | FK | CONCEPT | ||
relationship_id | Type de relation. | Identifiant de la relation (Maps to, Is a, etc.). | VARCHAR(20) | Oui | FK | RELATIONSHIP | ||
valid_start_date | Date de début de validité. | Date à partir de laquelle la relation est valide. | DATE | Oui | ||||
valid_end_date | Date de fin de validité. | Date jusqu'à laquelle la relation est valide. | DATE | Oui | ||||
invalid_reason | Raison d'invalidation. | NULL si valide, D = Deleted, U = Updated. | VARCHAR(1) | Non |
Guide Utilisateur
Relations clés : "Maps to" (mapping vers concept standard), "Is a" (hiérarchie parent-enfant), "Has ingredient" (composition des médicaments). Pour le mapping ETL, rechercher les relations "Maps to" depuis les concepts source vers les concepts standards.
Conventions ETL
Lors du mapping, utiliser la requête : SELECT concept_id_2 FROM concept_relationship WHERE concept_id_1 = [source_concept_id] AND relationship_id = 'Maps to' AND invalid_reason IS NULL. Les relations sont directionnelles ; la relation inverse existe souvent avec un relationship_id inverse.
RELATIONSHIP
Description de la table
La table RELATIONSHIP liste tous les types de relations possibles entre concepts. Chaque type de relation a une relation inverse correspondante, permettant la navigation bidirectionnelle dans le graphe de concepts.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
relationship_id | Identifiant de la relation. | Code de la relation (ex: Maps to, Is a). | VARCHAR(20) | Oui | PK | |||
relationship_name | Nom de la relation. | Description lisible de la relation. | VARCHAR(255) | Oui | ||||
is_hierarchical | Relation hiérarchique. | 1 si relation parent-enfant, 0 sinon. | VARCHAR(1) | Oui | ||||
defines_ancestry | Définit l'ascendance. | 1 si utilisée pour calculer CONCEPT_ANCESTOR. | VARCHAR(1) | Oui | ||||
reverse_relationship_id | Relation inverse. | ID de la relation inverse (ex: Mapped from). | VARCHAR(20) | Oui | FK | RELATIONSHIP | ||
relationship_concept_id | Concept représentant la relation. | Lien vers CONCEPT.concept_id. | INTEGER | Oui | FK | CONCEPT |
Guide Utilisateur
Relations principales : "Maps to" / "Mapped from" (mapping), "Is a" / "Subsumes" (hiérarchie), "Has ingredient" / "Ingredient of" (composition). Les relations hiérarchiques (is_hierarchical = 1) sont utilisées pour naviguer dans les arbres de concepts.
Conventions ETL
Table fournie par OHDSI. Les relations avec defines_ancestry = 1 sont utilisées pour calculer la table CONCEPT_ANCESTOR. Toujours utiliser la relation appropriée selon le sens de navigation souhaité.
CONCEPT_ANCESTOR
Description de la table
La table CONCEPT_ANCESTOR contient la fermeture transitive des hiérarchies de concepts. Elle permet de trouver rapidement tous les ancêtres ou descendants d'un concept sans parcourir récursivement les relations.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
ancestor_concept_id | Concept ancêtre (parent). | Concept plus général dans la hiérarchie. | INTEGER | Oui | FK | CONCEPT | ||
descendant_concept_id | Concept descendant (enfant). | Concept plus spécifique dans la hiérarchie. | INTEGER | Oui | FK | CONCEPT | ||
min_levels_of_separation | Distance minimale. | Nombre minimum de niveaux entre ancêtre et descendant. | INTEGER | Oui | ||||
max_levels_of_separation | Distance maximale. | Nombre maximum de niveaux entre ancêtre et descendant. | INTEGER | Oui |
Guide Utilisateur
CONCEPT_ANCESTOR est essentiel pour les requêtes inclusives. Par exemple, pour trouver tous les patients avec un "diabète", la requête inclut automatiquement "diabète de type 1", "diabète de type 2", etc. Chaque concept est aussi son propre ancêtre (min_levels = 0).
Conventions ETL
Table calculée par OHDSI à partir des relations hiérarchiques. Exemple de requête pour trouver tous les descendants : SELECT descendant_concept_id FROM concept_ancestor WHERE ancestor_concept_id = [parent_id]. Utiliser min_levels_of_separation = 0 pour inclure le concept lui-même.
SOURCE_TO_CONCEPT_MAP
Description de la table
La table SOURCE_TO_CONCEPT_MAP permet de stocker les mappings personnalisés entre les codes sources locaux et les concepts OMOP standards. Elle est utilisée lors de l'ETL pour convertir les terminologies locales.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
source_code | Code source local. | Valeur du code dans le système source. | VARCHAR(50) | Oui | ||||
source_concept_id | Concept source (si existant). | Concept OMOP non-standard correspondant au code source. | INTEGER | Oui | FK | CONCEPT | ||
source_vocabulary_id | Vocabulaire source. | Identifiant du vocabulaire local ou standard source. | VARCHAR(20) | Oui | FK | VOCABULARY | ||
source_code_description | Description du code source. | Libellé explicatif du code source. | VARCHAR(255) | Non | ||||
target_concept_id | Concept cible standard. | Concept OMOP standard vers lequel mapper. | INTEGER | Oui | FK | CONCEPT | ||
target_vocabulary_id | Vocabulaire cible. | Vocabulaire du concept cible (ex: SNOMED, RxNorm). | VARCHAR(20) | Oui | FK | VOCABULARY | ||
valid_start_date | Date de début de validité. | Date à partir de laquelle le mapping est valide. | DATE | Oui | ||||
valid_end_date | Date de fin de validité. | Date jusqu'à laquelle le mapping est valide. | DATE | Oui | ||||
invalid_reason | Raison d'invalidation. | NULL si valide, sinon raison de l'invalidation. | VARCHAR(1) | Non |
Guide Utilisateur
SOURCE_TO_CONCEPT_MAP est la table de travail pour l'ETL. Elle stocke les correspondances entre vos codes locaux (codes maison, codes établissement) et les concepts standards OMOP. C'est un complément à CONCEPT_RELATIONSHIP pour les vocabulaires non-standards.
Conventions ETL
Créer un vocabulary_id personnalisé pour votre source (ex: "HOPITAL_LOCAL"). Remplir cette table avant l'ETL avec tous les mappings nécessaires. Un même source_code peut mapper vers plusieurs target_concept_id si nécessaire. Documenter les mappings manuels pour la reproductibilité.
DRUG_STRENGTH
Description de la table
La table DRUG_STRENGTH contient les informations de dosage des médicaments. Elle détaille la quantité de principe actif par unité de forme pharmaceutique et permet le calcul des doses quotidiennes.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
drug_concept_id | Concept du médicament. | Lien vers CONCEPT.concept_id (domaine Drug). | INTEGER | Oui | FK | CONCEPT | Drug | |
ingredient_concept_id | Concept de l'ingrédient actif. | Principe actif du médicament. | INTEGER | Oui | FK | CONCEPT | Drug | |
amount_value | Quantité d'ingrédient. | Quantité par unité (ex: 500 pour 500mg/comprimé). | FLOAT | Non | ||||
amount_unit_concept_id | Unité de la quantité. | Concept d'unité (mg, g, UI, etc.). | INTEGER | Non | FK | CONCEPT | Unit | |
numerator_value | Numérateur de concentration. | Pour les solutions : quantité dans le numérateur. | FLOAT | Non | ||||
numerator_unit_concept_id | Unité du numérateur. | Unité de mesure du numérateur. | INTEGER | Non | FK | CONCEPT | Unit | |
denominator_value | Dénominateur de concentration. | Pour les solutions : volume ou quantité du dénominateur. | FLOAT | Non | ||||
denominator_unit_concept_id | Unité du dénominateur. | Unité de mesure du dénominateur (mL, L, etc.). | INTEGER | Non | FK | CONCEPT | Unit | |
box_size | Taille du conditionnement. | Nombre d'unités dans la boîte. | INTEGER | Non | ||||
valid_start_date | Date de début de validité. | Date de début de commercialisation. | DATE | Oui | ||||
valid_end_date | Date de fin de validité. | Date de fin (31-Dec-2099 si toujours valide). | DATE | Oui | ||||
invalid_reason | Raison d'invalidation. | NULL si valide, D ou U sinon. | VARCHAR(1) | Non |
Guide Utilisateur
DRUG_STRENGTH permet de calculer les doses administrées. Pour les formes solides, utiliser amount_value/amount_unit. Pour les liquides, utiliser le ratio numerator/denominator. Un médicament multi-ingrédient a plusieurs lignes, une par ingrédient.
Conventions ETL
Table fournie par OHDSI pour les vocabulaires RxNorm et RxNorm Extension. Utile pour standardiser les calculs de dose et pour les études de pharmacoépidémiologie. La formule DDD (Defined Daily Dose) peut être calculée à partir de ces données.
CONDITION_ERA
Description de la table
La table CONDITION_ERA contient des périodes continues pendant lesquelles un patient avait une condition. Elle agrège les enregistrements CONDITION_OCCURRENCE consécutifs ou proches pour former des épisodes de maladie.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
condition_era_id | Identifiant unique de l'ère de condition. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
person_id | Référence au patient. | Lien vers PERSON.person_id. | INTEGER | Oui | FK | PERSON | ||
condition_concept_id | Concept de la condition. | Concept standard de la condition (niveau ingrédient pour les maladies). | INTEGER | Oui | FK | CONCEPT | Condition | |
condition_era_start_date | Date de début de l'ère. | Premier jour de la période de condition. | DATE | Oui | ||||
condition_era_end_date | Date de fin de l'ère. | Dernier jour de la période de condition. | DATE | Oui | ||||
condition_occurrence_count | Nombre d'occurrences agrégées. | Nombre de CONDITION_OCCURRENCE dans cette ère. | INTEGER | Non |
Guide Utilisateur
CONDITION_ERA simplifie l'analyse des durées de maladie. Les conditions proches dans le temps (gap <= 30 jours par défaut) sont fusionnées en une seule ère. Utile pour identifier les patients avec une condition chronique ou les récidives.
Conventions ETL
Table dérivée, générée par un script ETL à partir de CONDITION_OCCURRENCE. L'algorithme standard utilise un gap de 30 jours pour fusionner les occurrences consécutives. Le condition_concept_id est standardisé au niveau le plus spécifique disponible.
DRUG_ERA
Description de la table
La table DRUG_ERA représente des périodes d'exposition continue à un principe actif (ingrédient). Elle agrège les DRUG_EXPOSURE pour créer des périodes de traitement cohérentes, en tenant compte des renouvellements d'ordonnance.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
drug_era_id | Identifiant unique de l'ère médicamenteuse. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
person_id | Référence au patient. | Lien vers PERSON.person_id. | INTEGER | Oui | FK | PERSON | ||
drug_concept_id | Concept du principe actif. | Concept de l'ingrédient (pas du médicament commercial). | INTEGER | Oui | FK | CONCEPT | Drug | |
drug_era_start_date | Date de début de l'ère. | Premier jour d'exposition au médicament. | DATE | Oui | ||||
drug_era_end_date | Date de fin de l'ère. | Dernier jour d'exposition (incluant la durée de la dernière prescription). | DATE | Oui | ||||
drug_exposure_count | Nombre d'expositions agrégées. | Nombre de DRUG_EXPOSURE dans cette ère. | INTEGER | Non | ||||
gap_days | Jours de gap cumulés. | Total des jours sans traitement au sein de l'ère. | INTEGER | Non |
Guide Utilisateur
DRUG_ERA représente l'exposition au niveau de l'ingrédient actif. Ainsi, des prescriptions d'Amoxicilline 500mg et d'Augmentin (amoxicilline + acide clavulanique) génèrent des ères distinctes pour chaque ingrédient. Utile pour les études de pharmacoépidémiologie.
Conventions ETL
Table dérivée à partir de DRUG_EXPOSURE. L'algorithme utilise un gap de 30 jours par défaut pour fusionner les expositions. Les drug_concept_id sont remontés au niveau ingrédient via les relations RxNorm. Le gap_days mesure la compliance du patient.
DOSE_ERA
Description de la table
La table DOSE_ERA représente des périodes d'exposition à une dose spécifique d'un médicament. Elle permet de suivre les changements de posologie au cours du temps pour un même traitement.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
dose_era_id | Identifiant unique de l'ère de dose. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
person_id | Référence au patient. | Lien vers PERSON.person_id. | INTEGER | Oui | FK | PERSON | ||
drug_concept_id | Concept du principe actif. | Concept de l'ingrédient. | INTEGER | Oui | FK | CONCEPT | Drug | |
unit_concept_id | Unité de la dose. | Concept d'unité (mg, g, UI, etc.). | INTEGER | Oui | FK | CONCEPT | Unit | |
dose_value | Valeur de la dose quotidienne. | Dose journalière pendant cette période. | FLOAT | Oui | ||||
dose_era_start_date | Date de début de l'ère de dose. | Premier jour à cette dose. | DATE | Oui | ||||
dose_era_end_date | Date de fin de l'ère de dose. | Dernier jour à cette dose. | DATE | Oui |
Guide Utilisateur
DOSE_ERA capture les changements de posologie. Un patient sous metformine passant de 500mg/jour à 1000mg/jour aura deux ères de dose distinctes. Utile pour les études de titration et d'efficacité dose-dépendante.
Conventions ETL
Table dérivée à partir de DRUG_EXPOSURE et DRUG_STRENGTH. La dose_value représente la dose quotidienne standardisée. Une nouvelle ère est créée à chaque changement de posologie. Moins fréquemment implémentée que DRUG_ERA.
COHORT
Description de la table
La table COHORT stocke les résultats des définitions de cohortes. Une cohorte est un ensemble de patients partageant des critères communs (exposition, condition, etc.) pendant une période définie.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
cohort_definition_id | Référence à la définition de cohorte. | Lien vers COHORT_DEFINITION.cohort_definition_id. | INTEGER | Oui | FK | COHORT_DEFINITION | ||
subject_id | Identifiant du sujet (patient). | Généralement person_id du patient. | INTEGER | Oui | ||||
cohort_start_date | Date d'entrée dans la cohorte. | Premier jour où le patient remplit les critères. | DATE | Oui | ||||
cohort_end_date | Date de sortie de la cohorte. | Dernier jour où le patient remplit les critères. | DATE | Oui |
Guide Utilisateur
COHORT est une table de résultats utilisée par les outils OHDSI comme ATLAS pour stocker les populations d'étude. Un patient peut appartenir à plusieurs cohortes et peut avoir plusieurs périodes dans une même cohorte (entrées/sorties multiples).
Conventions ETL
Table générée par les outils d'analyse, pas par l'ETL initial. Les cohortes sont définies via COHORT_DEFINITION et instanciées dans cette table. Le subject_id est généralement le person_id mais peut représenter d'autres entités selon le cas d'usage.
COHORT_DEFINITION
Description de la table
La table COHORT_DEFINITION stocke les définitions formelles des cohortes. Elle contient les métadonnées et la logique utilisée pour identifier les patients appartenant à chaque cohorte.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
cohort_definition_id | Identifiant unique de la définition. | Clé primaire de la définition de cohorte. | INTEGER | Oui | PK | |||
cohort_definition_name | Nom de la cohorte. | Nom descriptif de la population étudiée. | VARCHAR(255) | Oui | ||||
cohort_definition_description | Description de la cohorte. | Explication détaillée des critères d'inclusion/exclusion. | TEXT | Non | ||||
definition_type_concept_id | Type de définition. | Concept indiquant le type de définition. | INTEGER | Oui | FK | CONCEPT | ||
cohort_definition_syntax | Syntaxe de la définition. | Code ou requête définissant la cohorte (JSON ATLAS ou SQL). | TEXT | Non | ||||
subject_concept_id | Type de sujet. | Concept indiquant ce que représente le sujet (généralement Person). | INTEGER | Oui | FK | CONCEPT | ||
cohort_initiation_date | Date de création de la cohorte. | Date à laquelle la cohorte a été définie. | DATE | Non |
Guide Utilisateur
COHORT_DEFINITION décrit formellement comment une cohorte est construite. Les définitions peuvent être créées via ATLAS (interface graphique) et exportées en JSON, ou écrites directement en SQL. La reproductibilité des études repose sur ces définitions.
Conventions ETL
Table générée par les outils d'analyse. Le cohort_definition_syntax contient généralement du JSON ATLAS ou du SQL OHDSI. Documenter précisément les critères d'inclusion/exclusion dans cohort_definition_description pour la transparence scientifique.
CDM_SOURCE
Description de la table
La table CDM_SOURCE contient les métadonnées sur la source des données et l'instance CDM. Elle documente l'origine des données, la version du CDM utilisée, et les dates de couverture des données.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
cdm_source_name | Nom de la source CDM. | Nom identifiant cette instance de données. | VARCHAR(255) | Oui | ||||
cdm_source_abbreviation | Abréviation de la source. | Code court pour la source (ex: APHP, CHRU). | VARCHAR(25) | Oui | ||||
cdm_holder | Organisation responsable. | Nom de l'organisation gérant les données. | VARCHAR(255) | Oui | ||||
source_description | Description de la source. | Description détaillée de l'origine des données. | TEXT | Non | ||||
source_documentation_reference | Référence documentation. | URL ou citation vers la documentation source. | VARCHAR(255) | Non | ||||
cdm_etl_reference | Référence ETL. | Documentation du processus ETL utilisé. | VARCHAR(255) | Non | ||||
source_release_date | Date de publication des données source. | Date de l'extraction des données source. | DATE | Oui | ||||
cdm_release_date | Date de création du CDM. | Date à laquelle cette version du CDM a été créée. | DATE | Oui | ||||
cdm_version | Version du CDM. | Version OMOP CDM utilisée (ex: v5.4). | VARCHAR(10) | Non | ||||
cdm_version_concept_id | Concept de la version CDM. | Concept représentant la version du CDM. | INTEGER | Oui | FK | CONCEPT | ||
vocabulary_version | Version des vocabulaires. | Version des vocabulaires OHDSI utilisée. | VARCHAR(20) | Oui |
Guide Utilisateur
CDM_SOURCE est essentielle pour la traçabilité et la reproductibilité. Elle permet de savoir quelles données sont présentes, d'où elles viennent, et avec quelle version des outils elles ont été traitées. Cette table ne contient généralement qu'une seule ligne.
Conventions ETL
Remplir cette table à chaque nouveau chargement de données. Documenter la version des vocabulaires OHDSI (Athena) utilisée. Le cdm_etl_reference devrait pointer vers le code ETL ou sa documentation pour la reproductibilité.
METADATA
Description de la table
La table METADATA stocke des métadonnées structurées sous forme clé-valeur. Elle permet de documenter des informations supplémentaires sur les données CDM qui ne sont pas capturées dans CDM_SOURCE.
| Champ CDM | Guide Utilisateur | Conventions ETL | Type | Requis | PK | FK | Table FK | Domaine FK |
|---|---|---|---|---|---|---|---|---|
metadata_id | Identifiant unique de la métadonnée. | Clé primaire générée automatiquement. | INTEGER | Oui | PK | |||
metadata_concept_id | Concept de la métadonnée. | Concept identifiant le type de métadonnée. | INTEGER | Oui | FK | CONCEPT | ||
metadata_type_concept_id | Type de métadonnée. | Concept indiquant la nature de la métadonnée. | INTEGER | Oui | FK | CONCEPT | ||
name | Nom de la métadonnée. | Clé identifiant la métadonnée. | VARCHAR(250) | Oui | ||||
value_as_string | Valeur textuelle. | Valeur de la métadonnée en texte. | VARCHAR(250) | Non | ||||
value_as_concept_id | Valeur comme concept. | Valeur de la métadonnée comme concept OMOP. | INTEGER | Non | FK | CONCEPT | ||
value_as_number | Valeur numérique. | Valeur de la métadonnée en nombre. | FLOAT | Non | ||||
metadata_date | Date de la métadonnée. | Date associée à cette métadonnée. | DATE | Non | ||||
metadata_datetime | Date et heure de la métadonnée. | Horodatage de la métadonnée. | DATETIME | Non |
Guide Utilisateur
METADATA offre une flexibilité pour stocker des informations additionnelles non prévues par le schéma CDM standard. Par exemple : paramètres de configuration de l'ETL, statistiques sur les données, informations de qualité, ou métadonnées spécifiques au site.
Conventions ETL
Utiliser des concepts standards pour metadata_concept_id quand ils existent. Pour les métadonnées personnalisées, créer des concepts locaux. Cette table peut être utilisée pour stocker des informations d'audit, de traçabilité ou de configuration.
Commentaires