Kurze Antwort: Das OMOP Common Data Model (Observational Medical Outcomes Partnership CDM), das von der OHDSI-Community gepflegt wird, ist ein relationales Schema, in das Gesundheitsdaten aus jeder Quelle (elektronische Patientenakten, Abrechnungsdaten, Register) umgewandelt werden, zusammen mit einem Satz von standardisierten Vokabularen, die jeden lokalen Code einer Standard-Konzept-ID zuordnen. Sobald eine Datenbank im OMOP-Format vorliegt, kann derselbe Analysecode (eine Kohortendefinition, eine Inzidenzschätzung, eine vergleichende Wirksamkeitsstudie) unverändert auf Hunderte von Datenbanken weltweit angewendet werden, und nur aggregierte Ergebnisse werden geteilt. OMOP ist das Modell für die Forschung; FHIR ist das Modell für den Austausch und die Versorgung; eine veröffentlichte Zuordnung verbindet sie, und die meisten Forschungsplattformen akzeptieren mittlerweile FHIR als Quelle für ihre OMOP ETL.
Das Modell in einem Bild
Das OMOP Common Data Model stellt alles als ein Ereignis über eine Person während eines Beobachtungszeitraums dar, wobei die klinische Domäne die Tabelle bestimmt: condition_occurrence für Diagnosen, drug_exposure für Medikamente, measurement für Laborergebnisse und Vitalwerte, procedure_occurrence, visit_occurrence, observation für andere Fakten, plus die Tabellen person, death, note, specimen, provider und cost. Version 5.4 ist die am weitesten verbreitete.
Alles ist ein Ereignis über eine Person während eines Beobachtungszeitraums, wobei die klinische Domäne die Tabelle bestimmt:
| Tabelle | Enthält | Standardvokabular (typisch) | FHIR-Quelle |
|---|---|---|---|
| person | Eine Zeile pro Person: Geschlecht, Geburtsdatum, Rasse, Ethnie, Wohnort | Konzepte für Geschlecht, Rasse, Ethnie | Patient |
| observation_period | Zeiträume, in denen Daten über die Person erwartet werden | — | Abgeleitet aus Deckungs- und Begegnungsdaten |
| visit_occurrence (und visit_detail) | Begegnungen: stationär, ambulant, Notfall, mit Daten | Besuchskonzepte | Encounter |
| condition_occurrence | Diagnosen und Probleme mit Anfang und Ende | SNOMED CT | Condition (ICD-Codes zu SNOMED zugeordnet) |
| drug_exposure | Verschreibungen, Abgaben, Verabreichungen mit Menge und Tagesvorrat | RxNorm (und RxNorm Extension für nicht-US-Medikamente) | MedicationRequest, MedicationStatement, MedicationAdministration, MedicationDispense |
| procedure_occurrence | Durchgeführte Prozeduren | SNOMED CT, CPT4, ICD10PCS | Procedure |
| measurement | Laborergebnisse und Vitalwerte mit Wert, Einheit, Bereich | LOINC, mit UCUM-Einheiten | Observation (Labor, Vitalwerte) |
| observation | Andere klinische Fakten: Anamnese, sozial, Scores | SNOMED CT, LOINC | Observation (andere), QuestionnaireResponse, FamilyMemberHistory |
| device_exposure | Verwendete Geräte | SNOMED CT | DeviceUseStatement, Procedure |
| death | Datum und Ursache | SNOMED CT | Patient.deceased, Observation |
| note, note_nlp | Klinische Notizen und durch NLP extrahierte Begriffe | — | DocumentReference, DiagnosticReport |
| specimen | Proben | SNOMED CT | Specimen |
| provider, care_site, location | Kliniker, Einrichtungen, Orte | Spezialisierungskonzepte | Practitioner, Organization, Location |
| cost, payer_plan_period | Kosten und Deckung | — | Coverage, Claim (falls verfügbar) |
Version 5.4 ist die, die die meisten Standorte verwenden; Version 6 existiert, wurde aber nicht weit verbreitet angenommen, und die Entwicklung wird auf der 5.x-Linie fortgesetzt.
Die Vokabulare
Die OMOP standardisierten Vokabulare, die von OHDSI über Athena vertrieben werden, laden mehr als hundert Codesysteme (SNOMED CT, LOINC, RxNorm, ICD-10, ATC und andere) in die Tabellen concept, concept_relationship und concept_ancestor. Jeder Code wird zu einer concept_id, entweder als Standard oder zu einem Standard zugeordnet, sodass Analysen einmal geschrieben werden, während der ursprüngliche Quellcode erhalten bleibt.
Die zweite Hälfte von OMOP ist Athena, die Vokabularverteilung von OHDSI: mehr als hundert Codesysteme (SNOMED CT, LOINC, RxNorm, ICD-10 und nationale Varianten, ATC, CPT, Read und viele mehr), die in die Tabellen concept, concept_relationship, concept_ancestor geladen werden. Jeder Code wird zu einer concept_id; jedes Konzept ist entweder Standard (das, was Analysen verwenden), nicht-Standard (ein Quellcode, der einem Standard zugeordnet ist) oder eine Klassifizierung. Die ETL speichert sowohl das Quellkonzept (was der Datensatz sagte: ICD-10 E11.9) als auch das Standardkonzept (SNOMED 44054006), sodass Analysen einmal gegen Standardkonzepte geschrieben werden, während das Original erhalten bleibt. Die Tabelle concept_ancestor ermöglicht es einer Kohorte, mit einem einzigen Join nach "jeder Art von Diabetes" zu fragen. Sehen Sie SNOMED CT vs ICD-10 für den Grund, warum der Standard für Zustände SNOMED CT ist.
Die ETL
Die OMOP ETL ist die Arbeit der Konvertierung einer Quelldatenbank in das gemeinsame Datenmodell, unterstützt durch OHDSI-Tools: WhiteRabbit profiliert die Quelle, Rabbit-in-a-Hat dokumentiert die Tabellenzuordnung, Usagi ordnet lokale Codes Standardkonzepten zu, das Data Quality Dashboard prüft das Ergebnis anhand tausender Regeln und ACHILLES charakterisiert die fertige Datenbank.
Die Umwandlung einer Quelle in OMOP ist die Hauptarbeit. Die Werkzeuge von OHDSI helfen: WhiteRabbit scannt die Quelle und profiliert sie; Rabbit-in-a-Hat dokumentiert die Zuordnung von Quelltabellen zu CDM-Tabellen; Usagi hilft bei der Zuordnung lokaler Codes zu Standardkonzepten; das Data Quality Dashboard prüft das Ergebnis anhand tausender Regeln; ACHILLES charakterisiert die Datenbank. Typische Entscheidungen: wie Besuche definiert werden, wie Medikamentenaufzeichnungen zu Expositionen mit Tagesvorrat werden, wie Einheiten normalisiert werden, was mit Codes ohne Standardzuordnung zu tun ist und wie Updates behandelt werden (vollständiges Neuladen vs. inkrementell).
Analyse über das Netzwerk
Die Analyse über das OHDSI-Netzwerk funktioniert, indem eine Studie einmal geschrieben und überall ausgeführt wird: Forscher definieren Kohorten in ATLAS, führen Schätzungen und Vorhersagen mit den HADES R-Paketen durch und verpacken die Analyse als Code, den jede Stelle lokal auf ihrer eigenen OMOP-Datenbank ausführt und nur aggregierte Ergebnisse teilt. DARWIN EU und EHDEN folgen diesem Modell.
ATLAS ist das Web-Tool, mit dem Forscher Kohortendefinitionen (Personen mit Zustand X, die Medikament Y erhalten, innerhalb von Zeitfenstern) erstellen, diese charakterisieren und Schätz- und Vorhersagestudien mit den HADES R-Paketen (CohortMethod, PatientLevelPrediction, SelfControlledCaseSeries) durchführen. Eine Netzwerkstudie verpackt die Analyse als Code; jeder Standort führt sie lokal auf seiner OMOP-Datenbank aus und teilt aggregierte Ergebnisse; niemand fasst Datensätze auf Datensatzebene zusammen. So hat die OHDSI-Community während der Pandemie schnell große multinationale Studien durchgeführt, und dies ist das Modell hinter dem DARWIN EU-Netzwerk der EMA und dem EHDEN-Projekt, das mehr als hundert europäische Datenbanken in OMOP umgewandelt hat.
FHIR zu OMOP
FHIR wird auf zwei Ebenen auf OMOP abgebildet: Ressourcen auf Tabellen und Elemente auf Spalten, wobei FHIR-Codes über die OMOP-Vokabulare in Standardkonzepte übersetzt werden. Der FHIR-zu-OMOP-Implementierungsleitfaden von HL7 und die FHIR-Arbeitsgruppe von OHDSI veröffentlichen die Zuordnungen; mehrere Plattformen führen die ETL direkt von einem FHIR-Server oder einem Bulk-Data-Export aus.
FHIR und OMOP erfüllen unterschiedliche Bedürfnisse: FHIR überträgt den detaillierten Datensatz eines Patienten zwischen Systemen mit vollständiger Detailgenauigkeit; OMOP flacht die Datensätze vieler Patienten für statistische Analysen ab. Die Zuordnung ist auf Ressourcenebene (Tabelle oben) natürlich und auf Elementebene detailliert: FHIR-Codes werden über die OMOP-Vokabulare Standardkonzepten zugeordnet; Observation.valueQuantity wird zu measurement value_as_number mit unit_concept_id; Encounter.class wird zu visit_concept_id. HL7's FHIR to OMOP implementation guide (über den Vulcan-Beschleuniger) und die FHIR-Arbeitsgruppe von OHDSI veröffentlichen die Zuordnungen und Referenzimplementierungen; mehrere Plattformen führen die ETL direkt von einem FHIR-Server oder einem Bulk-Data-Export aus. Mehrdeutigkeiten bleiben bestehen, wo FHIR umfangreicher ist (mehrere Kodierungen, Status, Herkunft) oder wo OMOP etwas benötigt, das FHIR fehlt (Tagesvorrat, Beobachtungszeiträume).
Was OMOP nicht ist
OMOP ist kein Format für die Versorgung und nicht von sich aus anonym: Es verwirft Narrative, glättet Status und enthält keine Zustimmung, Herkunft oder Arbeitsabläufe, sodass FHIR das Austauschformat bleibt, und eine OMOP-Datenbank enthält immer noch Daten auf Datensatzebene, die wie jede Gesundheitsdatenbank verwaltet werden müssen, normalerweise mit pseudonymisierten Personen-IDs in einer sicheren Umgebung.
Es ist kein Format für die Versorgung: Es verwirft die Erzählung, flacht Status ab und überträgt keine Zustimmung, Herkunft oder Arbeitsabläufe. Es ist nicht von sich aus anonym: Eine OMOP-Datenbank enthält Daten auf Datensatzebene und wird wie jede Gesundheitsdatenbank verwaltet, normalerweise mit pseudonymisierten Personen-IDs und in sicheren Umgebungen. Sehen Sie Sekundäre Nutzung von Gesundheitsdaten und De-Identifizierung von Gesundheitsdaten.
In Anpheros
Anpheros-Datensätze sind FHIR R4 mit Standardcodes (LOINC, SNOMED CT, ATC, ICD-10), was die Eingabe ist, die eine OMOP ETL benötigt; mit der Zustimmung des Patienten für einen Forschungszweck können pseudonymisierte FHIR-Extrakte die ETL einer Forschungsplattform speisen. Anpheros selbst berechnet nur aggregierte Populationssignale über Gruppen von 20 oder mehr und betreibt keine OMOP-Datenbank mit identifizierten Daten.
Verwandte Seiten
- Sekundäre Nutzung von Gesundheitsdaten: die Karte
- SNOMED CT vs ICD-10
- De-Identifizierung von Gesundheitsdaten
- FHIR Bulk Data Export erklärt
- Terminologieserver erklärt
- RxNorm vs ATC
Quellen
- OHDSI: OMOP Common Data Model
- OHDSI: The Book of OHDSI
- OHDSI Athena: standardisierte Vokabulare
- OHDSI: ATLAS
- HL7 Vulcan: FHIR to OMOP implementation guide
- EHDEN project
- EMA: DARWIN EU
Häufige Fragen
Ist OMOP ein Ersatz für FHIR?
Nein. FHIR tauscht den detaillierten Datensatz eines Patienten zwischen Systemen aus; OMOP strukturiert viele Datensätze für statistische Analysen. Forschungsplattformen nehmen FHIR (oder andere Quellen) auf und produzieren OMOP.
Welche OMOP-Version sollte ich verwenden?
5.4 ist die weit verbreitete Version mit vollständiger Tool-Unterstützung; die meisten neuen Konvertierungen zielen darauf ab. Version 6 führte Änderungen ein, die die Community nicht breit annahm.
Warum ordnet OMOP ICD-Codes SNOMED CT zu?
Damit Analysen einmal gegen ein einziges, hierarchisches Standardvokabular für Zustände geschrieben werden können, unabhängig davon, ob die Quelle ICD-10, ICD-10-CM, ICD-9-CM oder Read-Codes verwendet hat. Der Quellcode wird daneben aufbewahrt.
Ist eine OMOP-Datenbank anonym?
Nicht von sich aus. Sie enthält Daten auf Datensatzebene, normalerweise mit pseudonymisierten Identifikatoren und ohne direkte Identifikatoren, und muss wie jede Gesundheitsdatenbank geschützt und verwaltet werden, typischerweise innerhalb einer sicheren Umgebung.
Kostenlos in der Sandbox testen
Ihr erster FHIR-Aufruf in 5 Minuten. Eine HL7 FHIR R4 API mit der Zustimmung des Patienten: probieren Sie sie in der Sandbox aus und verbinden Sie dann Ihre eigene App oder Ihr Kliniksystem.
Kostenlos · 30 synthetische Patienten · keine Karte
Anpheros entwickelt eine Patientenakte, die der Patient kontrolliert und mit jeder Klinik teilen kann, auf einer HL7 FHIR R4-Plattform mit Sitz in der EU. Diese Anleitungen helfen Ihnen, Ihre Gesundheit zu verstehen und zu organisieren; sie ersetzen nicht Ihren Arzt.
Über Anpheros →