Réponse courte : le Modèle de Données Commun OMOP (Observational Medical Outcomes Partnership CDM), maintenu par la communauté OHDSI, est un schéma relationnel dans lequel les données de santé de n'importe quelle source (DSE, réclamations, registres) sont converties, avec un ensemble de vocabulaires standardisés qui associent chaque code local à un identifiant de concept standard. Une fois qu'une base de données est au format OMOP, le même code d'analyse (une définition de cohorte, une estimation d'incidence, une étude d'efficacité comparative) s'exécute sans modification sur des centaines de bases de données dans le monde, et seuls les résultats agrégés sont partagés. OMOP est le modèle pour la recherche ; FHIR est le modèle pour l'échange et les soins ; une cartographie publiée les relie, et la plupart des plateformes de recherche acceptent désormais FHIR comme source pour leur ETL OMOP.
Le modèle en une image
Le modèle commun OMOP représente tout comme un événement concernant une personne pendant une période d'observation, le domaine clinique décidant de la table : condition_occurrence pour les diagnostics, drug_exposure pour les médicaments, measurement pour les résultats de laboratoire et les signes vitaux, procedure_occurrence, visit_occurrence, observation pour d'autres faits, plus les tables person, death, note, specimen, provider et cost. La version 5.4 est la plus largement utilisée.
Tout est un événement concernant une personne pendant une période d'observation, le domaine clinique décidant de la table :
| Table | Contient | Vocabulaire standard (typique) | Source FHIR |
|---|---|---|---|
| person | Une ligne par personne : genre, date de naissance, race, ethnie, lieu | Concepts de Genre, Race, Ethnie | Patient |
| observation_period | Périodes pendant lesquelles des données sur la personne sont attendues | — | Dérivé des dates de couverture et de rencontre |
| visit_occurrence (et visit_detail) | Rencontres : hospitalisation, ambulatoire, urgences, avec dates | Concepts de visite | Encounter |
| condition_occurrence | Diagnostics et problèmes avec début et fin | SNOMED CT | Condition (codes ICD mappés à SNOMED) |
| drug_exposure | Ordonnances, dispensations, administrations avec quantité et jours d'approvisionnement | RxNorm (et RxNorm Extension pour les médicaments non américains) | MedicationRequest, MedicationStatement, MedicationAdministration, MedicationDispense |
| procedure_occurrence | Procédures réalisées | SNOMED CT, CPT4, ICD10PCS | Procedure |
| measurement | Résultats de laboratoire et signes vitaux avec valeur, unité, plage | LOINC, avec unités UCUM | Observation (laboratoire, signes vitaux) |
| observation | Autres faits cliniques : historique, social, scores | SNOMED CT, LOINC | Observation (autres), QuestionnaireResponse, FamilyMemberHistory |
| device_exposure | Appareils utilisés | SNOMED CT | DeviceUseStatement, Procedure |
| death | Date et cause | SNOMED CT | Patient.deceased, Observation |
| note, note_nlp | Notes cliniques et termes extraits par NLP | — | DocumentReference, DiagnosticReport |
| specimen | Spécimens | SNOMED CT | Specimen |
| provider, care_site, location | Cliniciens, établissements, lieux | Concepts de spécialité | Practitioner, Organization, Location |
| cost, payer_plan_period | Coûts et couverture | — | Coverage, Claim (si disponible) |
La version 5.4 est celle utilisée par la plupart des sites ; la version 6 existe mais n'a pas été largement adoptée, et le développement continue sur la ligne 5.x.
Les vocabulaires
Les vocabulaires standardisés OMOP, distribués par OHDSI via Athena, chargent plus d'une centaine de systèmes de codes (SNOMED CT, LOINC, RxNorm, ICD-10, ATC et autres) dans les tables concept, concept_relationship et concept_ancestor. Chaque code devient un concept_id, soit standard, soit mappé à un standard, de sorte que les analyses sont écrites une seule fois tout en préservant le code source d'origine.
La seconde moitié d'OMOP est Athena, la distribution de vocabulaires d'OHDSI : plus d'une centaine de systèmes de codes (SNOMED CT, LOINC, RxNorm, ICD-10 et variantes nationales, ATC, CPT, Read, et bien d'autres) chargés dans les tables concept, concept_relationship, concept_ancestor. Chaque code devient un concept_id ; chaque concept est soit standard (celui utilisé par les analyses), non-standard (un code source qui correspond à un code standard) ou une classification. L'ETL stocke à la fois le concept source (ce que disait l'enregistrement : ICD-10 E11.9) et le concept standard (SNOMED 44054006), de sorte que les analyses sont écrites une fois contre les concepts standards tout en préservant l'original. La table concept_ancestor permet à une cohorte de demander "n'importe quel type de diabète" en une seule jointure. Voir SNOMED CT vs ICD-10 pour comprendre pourquoi le standard pour les conditions est SNOMED CT.
L'ETL
L'ETL OMOP est le travail de conversion d'une base de données source vers le modèle de données commun, soutenu par les outils OHDSI : WhiteRabbit profile la source, Rabbit-in-a-Hat documente le mappage des tables, Usagi mappe les codes locaux vers les concepts standards, le Data Quality Dashboard vérifie le résultat par rapport à des milliers de règles, et ACHILLES caractérise la base de données terminée.
Convertir une source en OMOP est le travail principal. Les outils d'OHDSI aident : WhiteRabbit scanne la source et la profile ; Rabbit-in-a-Hat documente le mappage des tables sources vers les tables CDM ; Usagi aide à mapper les codes locaux aux concepts standards ; le Data Quality Dashboard vérifie le résultat par rapport à des milliers de règles ; ACHILLES caractérise la base de données. Décisions typiques : comment les visites sont définies, comment les enregistrements de médicaments deviennent des expositions avec les jours d'approvisionnement, comment les unités sont normalisées, que faire des codes qui n'ont pas de mappage standard, et comment gérer les mises à jour (rechargement complet vs incrémental).
Analyse à travers le réseau
L'analyse à travers le réseau OHDSI fonctionne en écrivant une étude une seule fois et en l'exécutant partout : les chercheurs définissent des cohortes dans ATLAS, exécutent l'estimation et la prédiction avec les packages R HADES, et empaquètent l'analyse sous forme de code que chaque site exécute localement sur sa propre base de données OMOP, ne partageant que les résultats agrégés. DARWIN EU et EHDEN suivent ce modèle.
ATLAS est l'outil web où les chercheurs construisent des définitions de cohortes (personnes atteintes de la condition X, exposées au médicament Y, dans des fenêtres temporelles), les caractérisent et exécutent des études d'estimation et de prédiction avec les packages R HADES (CohortMethod, PatientLevelPrediction, SelfControlledCaseSeries). Une étude réseau emballe l'analyse sous forme de code ; chaque site l'exécute localement sur sa base de données OMOP et partage les résultats agrégés ; personne ne met en commun les données au niveau des enregistrements. C'est ainsi que la communauté OHDSI a produit rapidement de grandes études multinationales pendant la pandémie, et c'est le modèle derrière le réseau DARWIN EU de l'EMA et le projet EHDEN, qui a converti plus d'une centaine de bases de données européennes en OMOP.
FHIR vers OMOP
FHIR est mappé à OMOP à deux niveaux : les ressources aux tables et les éléments aux colonnes, avec les codes FHIR traduits via les vocabulaires OMOP en concepts standards. Le guide d'implémentation FHIR vers OMOP de HL7 et le groupe de travail FHIR d'OHDSI publient les mappages ; plusieurs plateformes exécutent l'ETL directement à partir d'un serveur FHIR ou d'une exportation de données en masse.
FHIR et OMOP répondent à des besoins différents : FHIR transporte le dossier d'un patient entre les systèmes avec tous les détails ; OMOP aplatit les dossiers de nombreux patients pour des statistiques. Le mappage est naturel au niveau des ressources (table ci-dessus) et détaillé au niveau des éléments : les codes FHIR sont mappés via les vocabulaires OMOP aux concepts standards ; Observation.valueQuantity devient measurement value_as_number avec unit_concept_id ; Encounter.class devient visit_concept_id. Le guide d'implémentation FHIR vers OMOP de HL7 (via l'accélérateur Vulcan) et le groupe de travail FHIR d'OHDSI publient les mappages et les implémentations de référence ; plusieurs plateformes exécutent l'ETL directement à partir d'un serveur FHIR ou d'une exportation de données en masse (Bulk Data). Des ambiguïtés subsistent là où FHIR est plus riche (multiples codages, statuts, provenance) ou là où OMOP a besoin de ce que FHIR n'a pas (jours d'approvisionnement, périodes d'observation).
Ce qu'OMOP n'est pas
OMOP n'est pas un format de soins et n'est pas anonyme en soi : il supprime le narratif, aplatit les statuts et ne porte pas de consentement, de provenance ou de flux de travail, de sorte que FHIR reste le format d'échange, et une base de données OMOP contient toujours des données au niveau de l'enregistrement qui doivent être gérées comme toute base de données de santé, généralement avec des identifiants de personne pseudonymisés au sein d'un environnement sécurisé.
Ce n'est pas un format pour les soins : il supprime le narratif, aplatit les statuts et ne transporte pas le consentement, la provenance ou le flux de travail. Il n'est pas anonyme en soi : une base de données OMOP contient des données au niveau des enregistrements et est régie comme toute base de données de santé, généralement avec des identifiants de personne pseudonymisés et dans des environnements sécurisés. Voir Utilisation secondaire des données de santé et Désidentification des données de santé.
Dans Anpheros
Les enregistrements Anpheros sont au format FHIR R4 avec des codes standards (LOINC, SNOMED CT, ATC, ICD-10), ce qui est l'entrée souhaitée par un ETL OMOP ; avec le consentement de la personne pour un objectif de recherche, des extraits FHIR pseudonymisés peuvent alimenter l'ETL d'une plateforme de recherche. Anpheros calcule lui-même uniquement des signaux de population agrégés sur des groupes de 20 personnes ou plus et n'exploite pas de base de données OMOP sur des données identifiées.
Pages connexes
- Utilisation secondaire des données de santé : la carte
- SNOMED CT vs ICD-10
- Désidentification des données de santé
- Exportation de données en masse FHIR expliquée
- Serveurs de terminologie expliqués
- RxNorm vs ATC
Sources
- OHDSI : Modèle de Données Commun OMOP
- OHDSI : Le Livre d'OHDSI
- OHDSI Athena : vocabulaires standardisés
- OHDSI : ATLAS
- HL7 Vulcan : guide d'implémentation FHIR vers OMOP
- Projet EHDEN
- EMA : DARWIN EU
Questions fréquentes
OMOP est-il un remplacement pour FHIR ?
Non. FHIR échange le dossier détaillé d'un patient entre les systèmes ; OMOP structure de nombreux dossiers pour l'analyse statistique. Les plateformes de recherche prennent FHIR (ou d'autres sources) en entrée et produisent OMOP.
Quelle version d'OMOP dois-je utiliser ?
5.4 est la version largement déployée avec un support complet des outils ; la plupart des nouvelles conversions la ciblent. La version 6 a introduit des changements que la communauté n'a pas adoptés largement.
Pourquoi OMOP mappe-t-il les codes ICD à SNOMED CT ?
Afin que les analyses puissent être écrites une seule fois contre un vocabulaire standard unique et hiérarchique pour les conditions, indépendamment du fait que la source ait utilisé ICD-10, ICD-10-CM, ICD-9-CM ou Read codes. Le code source est conservé à côté.
Une base de données OMOP est-elle anonyme ?
Pas en soi. Elle contient des données au niveau des enregistrements, généralement avec des identifiants pseudonymisés et sans identifiants directs, et doit être protégée et régie comme toute base de données de santé, typiquement au sein d'un environnement sécurisé.
Essayez gratuitement dans le sandbox
Votre premier appel FHIR en 5 minutes. Une API HL7 FHIR R4 avec le consentement du patient intégré : essayez-la dans le bac à sable, puis connectez votre propre application ou système de clinique.
Gratuit · 30 patients synthétiques · sans carte
Anpheros développe un dossier médical que le patient contrôle et peut partager avec n'importe quelle clinique, sur une plateforme HL7 FHIR R4, basée en UE. Ces guides vous aident à comprendre et organiser votre santé ; ils ne remplacent pas votre médecin.
À propos d'Anpheros →