Krótka odpowiedź: OMOP Common Data Model (Observational Medical Outcomes Partnership CDM), rozwijany przez społeczność OHDSI, to schemat relacyjny, do którego dane medyczne z dowolnego źródła (EHR, rozliczenia, rejestry) są konwertowane, wraz z zestawem standaryzowanych słowników, które mapują każdy lokalny kod na standardowy identyfikator koncepcji. Gdy baza danych jest w formacie OMOP, ten sam kod analizy (definicja kohorty, oszacowanie częstości, badanie porównujące skuteczność) działa niezmieniony na setkach baz danych na całym świecie, a udostępniane są tylko zagregowane wyniki. OMOP to model dla badań; FHIR to model dla wymiany i opieki; opublikowane mapowanie łączy je, a większość platform badawczych akceptuje teraz FHIR jako źródło dla swojego procesu ETL do OMOP.
Model w jednym obrazku
Wspólny Model Danych OMOP przedstawia wszystko jako zdarzenie dotyczące osoby w okresie obserwacji, a dziedzina kliniczna decyduje o tabeli: condition_occurrence dla diagnoz, drug_exposure dla leków, measurement dla wyników laboratoryjnych i parametrów życiowych, procedure_occurrence, visit_occurrence, observation dla innych faktów, a także tabele person, death, note, specimen, provider i cost. Wersja 5.4 jest najczęściej używana.
Wszystko jest zdarzeniem dotyczącym osoby w okresie obserwacji, a tabela zależy od dziedziny klinicznej:
| Tabela | Zawiera | Standardowy słownik (typowa) | Źródło FHIR |
|---|---|---|---|
| person | Jeden wiersz na osobę: płeć, data urodzenia, rasa, pochodzenie etniczne, lokalizacja | Koncepcje płci, rasy, pochodzenia etnicznego | Patient |
| observation_period | Okresy, w których oczekiwane są dane o osobie | — | Wywnioskowane z dat ubezpieczenia i wizyt |
| visit_occurrence (i visit_detail) | Wizyty: pobyt stacjonarny, ambulatoryjny, nagły, z datami | Koncepcje wizyt | Encounter |
| condition_occurrence | Diagnozy i problemy z datą rozpoczęcia i zakończenia | SNOMED CT | Condition (kody ICD zmapowane do SNOMED) |
| drug_exposure | Recepty, wydania leków, podania z ilością i liczbą dni leczenia | RxNorm (i RxNorm Extension dla leków spoza USA) | MedicationRequest, MedicationStatement, MedicationAdministration, MedicationDispense |
| procedure_occurrence | Wykonane procedury | SNOMED CT, CPT4, ICD10PCS | Procedure |
| measurement | Wyniki badań laboratoryjnych i parametry życiowe z wartością, jednostką, zakresem | LOINC, z jednostkami UCUM | Observation (laboratoryjne, parametry życiowe) |
| observation | Inne fakty kliniczne: historia, społeczne, oceny | SNOMED CT, LOINC | Observation (inne), QuestionnaireResponse, FamilyMemberHistory |
| device_exposure | Używane urządzenia | SNOMED CT | DeviceUseStatement, Procedure |
| death | Data i przyczyna | SNOMED CT | Patient.deceased, Observation |
| note, note_nlp | Notatki kliniczne i terminy wyodrębnione przez NLP | — | DocumentReference, DiagnosticReport |
| specimen | Próbki | SNOMED CT | Specimen |
| provider, care_site, location | Lekarze, placówki, miejsca | Koncepcje specjalizacji | Practitioner, Organization, Location |
| cost, payer_plan_period | Koszty i ubezpieczenie | — | Coverage, Claim (jeśli dostępne) |
Wersja 5.4 jest najczęściej używana przez większość placówek; wersja 6 istnieje, ale nie została szeroko przyjęta, a rozwój jest kontynuowany w linii 5.x.
Słowniki
Standaryzowane słowniki OMOP, dystrybuowane przez OHDSI za pośrednictwem Atheny, ładują ponad sto systemów kodowania (SNOMED CT, LOINC, RxNorm, ICD-10, ATC i inne) do tabel concept, concept_relationship i concept_ancestor. Każdy kod staje się concept_id, albo standardowym, albo zmapowanym do standardowego, dzięki czemu analizy są pisane raz, a oryginalny kod źródłowy jest zachowany.
Drugą połowę OMOP stanowi Athena, dystrybutor słowników OHDSI: ponad sto systemów kodowania (SNOMED CT, LOINC, RxNorm, ICD-10 i warianty krajowe, ATC, CPT, Read i wiele innych) załadowanych do tabel concept, concept_relationship, concept_ancestor. Każdy kod staje się concept_id; każda koncepcja jest albo standardowa (ta, której używają analizy), niestandardowa (kod źródłowy, który mapuje się do standardowego) lub klasyfikacją. ETL przechowuje zarówno koncepcję źródłową (co mówiło rekord: ICD-10 E11.9), jak i koncepcję standardową (SNOMED 44054006), dzięki czemu analizy są pisane raz dla koncepcji standardowych, a oryginał jest zachowany. Tabela concept_ancestor pozwala kohorcie na zapytanie o "dowolny typ cukrzycy" w jednym połączeniu. Zobacz SNOMED CT vs ICD-10, dlaczego standardem dla schorzeń jest SNOMED CT.
ETL
ETL OMOP to praca polegająca na konwersji bazy danych źródłowych do wspólnego modelu danych, wspierana przez narzędzia OHDSI: WhiteRabbit profiluje źródło, Rabbit-in-a-Hat dokumentuje mapowanie tabel, Usagi mapuje lokalne kody do standardowych koncepcji, Data Quality Dashboard sprawdza wynik pod kątem tysięcy reguł, a ACHILLES charakteryzuje ukończoną bazę danych.
Konwersja źródła do OMOP to główna praca. Narzędzia OHDSI pomagają: WhiteRabbit skanuje źródło i profiluje je; Rabbit-in-a-Hat dokumentuje mapowanie z tabel źródłowych do tabel CDM; Usagi pomaga mapować lokalne kody do standardowych koncepcji; Data Quality Dashboard sprawdza wynik pod kątem tysięcy reguł; ACHILLES charakteryzuje bazę danych. Typowe decyzje: jak definiowane są wizyty, jak rekordy leków stają się ekspozycjami z liczbą dni leczenia, jak normalizowane są jednostki, co robić z kodami, które nie mają standardowego mapowania, i jak obsługiwać aktualizacje (pełne przeładowanie vs przyrostowe).
Analiza w sieci
Analiza w sieci OHDSI działa poprzez napisanie jednego badania i uruchomienie go wszędzie: badacze definiują kohorty w ATLAS, przeprowadzają estymację i predykcję za pomocą pakietów R HADES, a następnie pakują analizę jako kod, który każdy ośrodek wykonuje lokalnie na swojej własnej bazie danych OMOP, udostępniając jedynie zagregowane wyniki. DARWIN EU i EHDEN podążają za tym modelem.
ATLAS to narzędzie internetowe, w którym badacze tworzą definicje kohort (osoby ze schorzeniem X, narażone na lek Y, w określonych oknach czasowych), charakteryzują je i przeprowadzają badania estymacyjne i predykcyjne za pomocą pakietów R HADES (CohortMethod, PatientLevelPrediction, SelfControlledCaseSeries). Badanie sieciowe pakuje analizę jako kod; każda placówka uruchamia ją lokalnie na swojej bazie danych OMOP i udostępnia zagregowane wyniki; nikt nie łączy danych na poziomie rekordów. W ten sposób społeczność OHDSI szybko przeprowadziła duże międzynarodowe badania podczas pandemii, i jest to model stojący za siecią DARWIN EU EMA i projektem EHDEN, który przekształcił ponad sto europejskich baz danych do formatu OMOP.
FHIR do OMOP
FHIR mapuje się do OMOP na dwóch poziomach: zasoby do tabel i elementy do kolumn, z kodami FHIR tłumaczącymi się za pośrednictwem słowników OMOP na standardowe koncepcje. Przewodnik implementacyjny FHIR do OMOP firmy HL7 i grupa robocza FHIR OHDSI publikują mapowania; kilka platform uruchamia ETL bezpośrednio z serwera FHIR lub eksportu danych zbiorczych (Bulk Data).
FHIR i OMOP odpowiadają na różne potrzeby: FHIR przenosi szczegółowy rekord jednego pacjenta między systemami z pełnymi szczegółami; OMOP spłaszcza rekordy wielu pacjentów do celów statystycznych. Mapowanie jest naturalne na poziomie zasobów (tabela powyżej) i szczegółowe na poziomie elementów: kody FHIR są mapowane przez słowniki OMOP do standardowych koncepcji; Observation.valueQuantity staje się measurement value_as_number z unit_concept_id; Encounter.class staje się visit_concept_id. Przewodnik implementacyjny FHIR do OMOP HL7 (poprzez akcelerator Vulcan) i grupa robocza FHIR OHDSI publikują mapowania i referencyjne implementacje; kilka platform uruchamia ETL bezpośrednio z serwera FHIR lub eksportu danych masowych. Pozostają niejasności tam, gdzie FHIR jest bogatszy (wiele kodowań, statusów, pochodzenia) lub gdzie OMOP potrzebuje tego, czego FHIR brakuje (liczba dni leczenia, okresy obserwacji).
Czym OMOP nie jest
OMOP nie jest formatem opieki i sam w sobie nie jest anonimowy: usuwa narrację, spłaszcza statusy i nie zawiera zgody, pochodzenia ani przepływu pracy, dlatego FHIR pozostaje formatem wymiany, a baza danych OMOP nadal przechowuje dane na poziomie rekordu, które muszą być zarządzane jak każda baza danych medycznych, zazwyczaj z pseudonimizowanymi identyfikatorami osób w bezpiecznym środowisku.
Nie jest to format opieki: usuwa narrację, spłaszcza statusy i nie przenosi zgody, pochodzenia ani przepływu pracy. Sam w sobie nie jest anonimowy: baza danych OMOP zawiera dane na poziomie rekordów i jest zarządzana jak każda baza danych medycznych, zazwyczaj z pseudonimizowanymi identyfikatorami osób i w bezpiecznych środowiskach. Zobacz Wtórne wykorzystanie danych medycznych i Anonimizacja danych medycznych.
W Anpheros
Rekordy Anpheros są w formacie FHIR R4 ze standardowymi kodami (LOINC, SNOMED CT, ATC, ICD-10), co jest wejściem, którego potrzebuje ETL OMOP; za zgodą pacjenta na cel badawczy, pseudonimizowane wyciągi FHIR mogą zasilać ETL platformy badawczej. Sam Anpheros oblicza tylko zagregowane sygnały populacyjne dla grup liczących 20 lub więcej osób i nie obsługuje bazy danych OMOP na danych zidentyfikowanych.
Powiązane strony
- Wtórne wykorzystanie danych medycznych: mapa
- SNOMED CT vs ICD-10
- Anonimizacja danych medycznych
- Wyjaśnienie eksportu danych masowych FHIR
- Wyjaśnienie serwerów terminologicznych
- RxNorm vs ATC
Źródła
- OHDSI: OMOP Common Data Model
- OHDSI: The Book of OHDSI
- OHDSI Athena: standaryzowane słowniki
- OHDSI: ATLAS
- HL7 Vulcan: przewodnik implementacyjny FHIR do OMOP
- Projekt EHDEN
- EMA: DARWIN EU
Najczęstsze pytania
Czy OMOP zastępuje FHIR?
Nie. FHIR wymienia szczegółowy rekord jednego pacjenta między systemami; OMOP strukturyzuje wiele rekordów do analiz statystycznych. Platformy badawcze przyjmują FHIR (lub inne źródła) i generują OMOP.
Z której wersji OMOP powinienem skorzystać?
5.4 to szeroko stosowana wersja z pełnym wsparciem narzędzi; większość nowych konwersji jest do niej kierowana. Wersja 6 wprowadziła zmiany, których społeczność nie przyjęła powszechnie.
Dlaczego OMOP mapuje kody ICD na SNOMED CT?
Aby analizy mogły być pisane raz dla jednego, hierarchicznego standardowego słownika schorzeń, niezależnie od tego, czy źródło używało kodów ICD-10, ICD-10-CM, ICD-9-CM czy Read. Kod źródłowy jest zachowywany obok.
Czy baza danych OMOP jest anonimowa?
Nie sama w sobie. Zawiera dane na poziomie rekordów, zazwyczaj z pseudonimizowanymi identyfikatorami i bez bezpośrednich identyfikatorów, i musi być chroniona i zarządzana jak każda baza danych medycznych, zazwyczaj w bezpiecznym środowisku.
Wypróbuj za darmo w sandboksie
Pierwsze wywołanie FHIR w 5 minut. API HL7 FHIR R4 z wbudowaną zgodą pacjenta: wypróbuj w piaskownicy, a następnie połącz własną aplikację lub system kliniczny.
Za darmo · 30 syntetycznych pacjentów · bez karty
Anpheros tworzy dokumentację medyczną, nad którą pacjent ma kontrolę i którą może udostępniać dowolnej klinice, na platformie HL7 FHIR R4, z siedzibą w UE. Te przewodniki pomogą Ci zrozumieć i uporządkować informacje o Twoim zdrowiu; nie zastępują one wizyty u lekarza.
O Anpheros →