Коротка відповідь: OMOP Common Data Model (Observational Medical Outcomes Partnership CDM), який підтримується спільнотою OHDSI, — це реляційна схема, в яку перетворюються медичні дані з будь-якого джерела (EHR, страхові дані, реєстри), разом із набором стандартизованих словників, що зіставляють кожен локальний код зі стандартним ідентифікатором концепції. Після того, як база даних переведена в OMOP, той самий код аналізу (визначення когорти, оцінка частоти, дослідження порівняльної ефективності) працює без змін на сотнях баз даних по всьому світу, і лише агреговані результати передаються. OMOP — це модель для досліджень; FHIR — це модель для обміну даними та догляду; опубліковане зіставлення пов'язує їх, і більшість дослідницьких платформ зараз приймають FHIR як джерело для свого OMOP ETL.
Модель на одному зображенні
Загальна модель даних OMOP представляє все як подію, пов'язану з особою протягом періоду спостереження. Клінічна галузь визначає таблицю: condition_occurrence для діагнозів, drug_exposure для ліків, measurement для лабораторних результатів та показників життєдіяльності, procedure_occurrence, visit_occurrence, observation для інших фактів, а також таблиці person, death, note, specimen, provider та cost. Версія 5.4 є найпоширенішою.
Все є подією про особу протягом періоду спостереження, а клінічна галузь визначає таблицю:
| Таблиця | Містить | Стандартний словник (типовий) | Джерело FHIR |
|---|---|---|---|
| person | Один рядок на особу: стать, дата народження, раса, етнічна приналежність, місцезнаходження | Концепції статі, раси, етнічної приналежності | Patient |
| observation_period | Періоди, протягом яких очікуються дані про особу | — | Виводиться з дат покриття та візитів |
| visit_occurrence (і visit_detail) | Візити: стаціонарні, амбулаторні, екстрені, з датами | Концепції візитів | Encounter |
| condition_occurrence | Діагнози та проблеми з датою початку та закінчення | SNOMED CT | Condition (коди ICD зіставлені з SNOMED) |
| drug_exposure | Рецепти, видача ліків, введення з кількістю та тривалістю днів | RxNorm (і RxNorm Extension для ліків не з США) | MedicationRequest, MedicationStatement, MedicationAdministration, MedicationDispense |
| procedure_occurrence | Виконані процедури | SNOMED CT, CPT4, ICD10PCS | Procedure |
| measurement | Результати лабораторних досліджень та життєві показники зі значенням, одиницею вимірювання, діапазоном | LOINC, з одиницями UCUM | Observation (laboratory, vital signs) |
| observation | Інші клінічні факти: історія хвороби, соціальні фактори, оцінки | SNOMED CT, LOINC | Observation (other), QuestionnaireResponse, FamilyMemberHistory |
| device_exposure | Використані пристрої | SNOMED CT | DeviceUseStatement, Procedure |
| death | Дата та причина смерті | SNOMED CT | Patient.deceased, Observation |
| note, note_nlp | Клінічні нотатки та терміни, витягнуті за допомогою NLP | — | DocumentReference, DiagnosticReport |
| specimen | Зразки | SNOMED CT | Specimen |
| provider, care_site, location | Лікарі, заклади, місця | Концепції спеціальностей | Practitioner, Organization, Location |
| cost, payer_plan_period | Витрати та покриття | — | Coverage, Claim (де доступно) |
Версія 5.4 є тією, яку використовує більшість сайтів; версія 6 існує, але не отримала широкого поширення, і розробка продовжується в лінійці 5.x.
Словники
Стандартизовані словники OMOP, які OHDSI розповсюджує через Athena, завантажують понад сто кодових систем (SNOMED CT, LOINC, RxNorm, ICD-10, ATC та інші) до таблиць concept, concept_relationship та concept_ancestor. Кожен код стає concept_id, або стандартним, або зіставленим зі стандартним, тому аналізи пишуться один раз, а вихідний код зберігається.
Друга половина OMOP — це Athena, дистрибутив словників OHDSI: понад сто систем кодування (SNOMED CT, LOINC, RxNorm, ICD-10 та національні варіанти, ATC, CPT, Read та багато інших), завантажених у таблиці concept, concept_relationship, concept_ancestor. Кожен код стає concept_id; кожна концепція є стандартною (тією, яку використовують аналізи), нестандартною (вихідний код, що зіставляється зі стандартною) або класифікацією. ETL зберігає як вихідну концепцію (що було в записі: ICD-10 E11.9), так і стандартну концепцію (SNOMED 44054006), тому аналізи пишуться один раз проти стандартних концепцій, зберігаючи оригінал. Таблиця concept_ancestor дозволяє когорті запитувати "будь-який тип діабету" одним з'єднанням. Див. SNOMED CT проти ICD-10 щодо причин, чому стандартом для станів є SNOMED CT.
ETL
ETL OMOP — це робота з перетворення вихідної бази даних у загальну модель даних, що підтримується інструментами OHDSI: WhiteRabbit створює профіль вихідних даних, Rabbit-in-a-Hat документує зіставлення таблиць, Usagi зіставляє локальні коди зі стандартними концепціями, Data Quality Dashboard перевіряє результат за тисячами правил, а ACHILLES характеризує готову базу даних.
Перетворення вихідних даних в OMOP — це основна робота. Інструменти OHDSI допомагають: WhiteRabbit сканує вихідні дані та створює їх профіль; Rabbit-in-a-Hat документує зіставлення з вихідних таблиць до таблиць CDM; Usagi допомагає зіставляти локальні коди зі стандартними концепціями; Data Quality Dashboard перевіряє результат на відповідність тисячам правил; ACHILLES характеризує базу даних. Типові рішення: як визначаються візити, як записи про ліки стають експозиціями з тривалістю днів, як нормалізуються одиниці вимірювання, що робити з кодами, які не мають стандартного зіставлення, і як обробляти оновлення (повне перезавантаження проти інкрементного).
Аналіз у мережі
Аналіз у мережі OHDSI працює шляхом написання одного дослідження та його виконання скрізь: дослідники визначають когорти в ATLAS, проводять оцінку та прогнозування за допомогою пакетів R HADES, а також пакують аналіз як код, який кожен сайт виконує локально на своїй базі даних OMOP, обмінюючись лише агрегованими результатами. DARWIN EU та EHDEN дотримуються цієї моделі.
ATLAS — це веб-інструмент, де дослідники створюють визначення когорт (люди з станом X, які отримували препарат Y, протягом часових вікон), характеризують їх та проводять дослідження оцінки та прогнозування за допомогою пакетів R HADES (CohortMethod, PatientLevelPrediction, SelfControlledCaseSeries). Мережеве дослідження пакує аналіз як код; кожен сайт запускає його локально на своїй базі даних OMOP та ділиться агрегованими результатами; ніхто не об'єднує дані на рівні записів. Саме так спільнота OHDSI швидко провела великі багатонаціональні дослідження під час пандемії, і це модель, що лежить в основі мережі DARWIN EU EMA та проекту EHDEN, який перетворив понад сто європейських баз даних на OMOP.
FHIR до OMOP
FHIR зіставляється з OMOP на двох рівнях: ресурси до таблиць, а елементи до стовпців, при цьому коди FHIR перетворюються через словники OMOP на стандартні концепції. Посібник з реалізації FHIR до OMOP від HL7 та робоча група FHIR OHDSI публікують зіставлення; кілька платформ виконують ETL безпосередньо з сервера FHIR або експорту Bulk Data.
FHIR та OMOP відповідають різним потребам: FHIR передає детальний запис одного пацієнта між системами; OMOP узагальнює записи багатьох пацієнтів для статистичного аналізу. Зіставлення є природним на рівні ресурсів (таблиця вище) та детальним на рівні елементів: коди FHIR зіставляються через словники OMOP до стандартних концепцій; Observation.valueQuantity стає measurement value_as_number з unit_concept_id; Encounter.class стає visit_concept_id. Посібник з впровадження FHIR до OMOP від HL7 (через прискорювач Vulcan) та робоча група FHIR OHDSI публікують зіставлення та референсні реалізації; кілька платформ запускають ETL безпосередньо з FHIR-сервера або експорту Bulk Data. Залишаються неоднозначності там, де FHIR є більш детальним (кілька кодувань, статусів, походження) або де OMOP потребує того, чого бракує в FHIR (тривалість днів, періоди спостереження).
Чим OMOP не є
OMOP не є форматом для надання медичної допомоги і сам по собі не є анонімним: він відкидає наратив, згладжує статуси та не містить згоди, походження чи робочого процесу, тому FHIR залишається форматом обміну, а база даних OMOP все ще містить дані на рівні записів, якими слід керувати, як і будь-якою медичною базою даних, зазвичай з псевдонімізованими ідентифікаторами особи в безпечному середовищі.
Це не формат для догляду: він відкидає наратив, узагальнює статуси та не передає згоду, походження чи робочий процес. Сам по собі він не є анонімним: база даних OMOP містить дані на рівні записів і керується як будь-яка медична база даних, зазвичай з псевдонімізованими ідентифікаторами осіб та в безпечних середовищах. Див. Вторинне використання медичних даних та Деідентифікація медичних даних.
В Anpheros
Записи Anpheros є FHIR R4 зі стандартними кодами (LOINC, SNOMED CT, ATC, ICD-10), що є вхідними даними, які потребує OMOP ETL; за згодою особи для дослідницьких цілей, псевдонімізовані витяги FHIR можуть подаватися до ETL дослідницької платформи. Anpheros сам обчислює лише агреговані популяційні сигнали для груп від 20 або більше осіб і не працює з базою даних OMOP на ідентифікованих даних.
Пов'язані сторінки
- Вторинне використання медичних даних: карта
- SNOMED CT проти ICD-10
- Деідентифікація медичних даних
- Пояснення експорту FHIR Bulk Data
- Пояснення серверів термінології
- RxNorm проти ATC
Джерела
- OHDSI: OMOP Common Data Model
- OHDSI: The Book of OHDSI
- OHDSI Athena: стандартизовані словники
- OHDSI: ATLAS
- HL7 Vulcan: посібник з впровадження FHIR до OMOP
- Проект EHDEN
- EMA: DARWIN EU
Поширені запитання
Чи є OMOP заміною FHIR?
Ні. FHIR обмінюється детальним записом одного пацієнта між системами; OMOP структурує багато записів для статистичного аналізу. Дослідницькі платформи приймають FHIR (або інші джерела) і створюють OMOP.
Яку версію OMOP слід використовувати?
5.4 — це широко розгорнута версія з повною підтримкою інструментів; більшість нових перетворень націлені на неї. Версія 6 внесла зміни, які спільнота не прийняла широко.
Чому OMOP зіставляє коди ICD зі SNOMED CT?
Щоб аналізи можна було писати один раз проти єдиного, ієрархічного стандартного словника для станів, незалежно від того, чи використовувало джерело коди ICD-10, ICD-10-CM, ICD-9-CM або Read. Вихідний код зберігається поруч.
Чи є база даних OMOP анонімною?
Не сама по собі. Вона містить дані на рівні записів, зазвичай з псевдонімізованими ідентифікаторами та без прямих ідентифікаторів, і повинна захищатися та керуватися як будь-яка медична база даних, зазвичай у безпечному середовищі.
Спробуйте безкоштовно в пісочниці
Перший запит FHIR за 5 хвилин. API стандарту HL7 FHIR R4 з вбудованою згодою пацієнта: спробуйте в пісочниці, а потім підключіть власну програму чи клінічну систему.
Безкоштовно · 30 синтетичних пацієнтів · без картки
Anpheros створює медичну карту, яку пацієнт контролює та може ділитися з будь-якою клінікою, на платформі HL7 FHIR R4, розташованій в ЄС. Ці посібники допоможуть вам зрозуміти та організувати своє здоров'я; вони не замінюють вашого лікаря.
Про Anpheros →